Richard Feldman (Aug 06 2023 at 15:29): Richard Feldman (Aug 06 2023 at 15:29):so right now in basic-cli we have Stdout.line for printing a line to stdout.
now that we have a design for platform-agnostic effects (which we didn't back when that name was chosen), it seems like in the future we'll instead want to have a function that is platform-agnostic instead
Richard Feldman (Aug 06 2023 at 15:30):one situation where the name might want to be different is in a platform that runs in the browser, where it would do console.log instead of writing to stdout
Richard Feldman (Aug 06 2023 at 15:31):and maybe in a game engine or editor plugin it might write to some concept of a console they have
Richard Feldman (Aug 06 2023 at 15:32):so at first I was thinking of the name Console.line but then there's no obvious equivalent of writing to stderr
Richard Feldman (Aug 06 2023 at 15:33):but then again, it's not a given that such a thing would exist. Like in the browser there's console.warn and console.error but in a game engine maybe there's just one console
Richard Feldman (Aug 06 2023 at 15:34):but then again, NodeJS is in a similar boat regarding console.warn and console.error (I assume it just has both of them write to stderr, although I haven't experimented with it)
Richard Feldman (Aug 06 2023 at 15:36):along similar lines, I think it's safe to assume there's no equivalent of "read from stdin" for a module like Console, so I think a platform-agnostic Console would have to be scoped to output only
Richard Feldman (Aug 06 2023 at 15:38):also I don't think it's safe to assume every platform would have a natural equivalent of "write less than a full line" like there is in stdout and stderr (e.g. print as opposed to println), although I guess you could implement your own buffer using Stored if that was desired
Richard Feldman (Aug 06 2023 at 15:39):so one idea would be to have like:
Console.outConsole.warnConsole.errand then in a CLI platform the last two would both just write to stderr, whereas in a browser platform they would do something different
Richard Feldman (Aug 06 2023 at 15:42):another possible design would be to have 1 or 2 of the above but not all 3
Richard Feldman (Aug 06 2023 at 15:42):I'm curious what others think about this!
Richard Feldman (Aug 06 2023 at 15:45):I guess another possibility is that this doesn't actually make sense as a platform-agnostic effect
Richard Feldman (Aug 06 2023 at 15:46):because for that to be desirable, you'd want to write a package which directly writes to stdout/stderr or does console.log
Richard Feldman (Aug 06 2023 at 15:46):which kinda sounds like a default bad idea?
Richard Feldman (Aug 06 2023 at 15:48):I'm not sure what type of package (as opposed to application) would actually involve writing directly to stdout/stderr as the optimal design :thinking:
Bálint Harmat (Aug 06 2023 at 19:33):I wonder what are your general thoughts on logging with regards to this topic. Should logging default to console output? Do you envision a separate Logging specific side effect?
If the former, the platform agnostic functions could be just called Log.info, Log.warn, Log.error. This also nicely communicates that this is an output only kind of thing, and you won't have to add a FAQ about where is the Console.ReadLine.
Personally I would have all 3, and if a platform has to just output all 3 to the same place, they can prepend it with info: etc. (but no "less than a full line" leave that to a platform that is specialized in CLI based UI)
Brendan Hansknecht (Aug 06 2023 at 20:00):I guess another possibility is that this doesn't actually make sense as a platform-agnostic effect
I think this is the correct stance with a caveat. I still think we should have a first class concept of logging that is built into the language. A platform can always choose not to implement it, but I think it should be handled directly instead of through effects. It is just too useful in otherwise totally effect free code.
Last updated: Jun 16 2026 at 16:19 UTC