How to do console I/O? about rio HOT 13 CLOSED

I'm not necessarily against simply continuing your tradition of naming things what they do, e.g.

displayUtf8 :: (MonadIO m, Display a) => a -> m ()
writeUtf8 :: (MonadIO m) => Text -> m ()
writeBytes :: (MonadIO m) => ByteString -> m ()
writeBuilder :: (MonadIO m) => Builder -> m ()

Or whatever. I always liked that decodeUtf8 made you think about what you were doing when you use it.

from rio.

I think we've done as much here as we intend to, closing.

from rio.

And I would let it registered that a rio-text-icu at some point would be a useful addition.

from rio.

Regarding logging, it's worth keeping in mind output that a programmer might want to redirect to a file (like the result of the program), and the logging outputting to stderr.

from rio.

Regarding the discussed sibling package: https://github.com/snoyberg/codename-karka/issues/11

from rio.

I've been thinking about this since closing #34. So far I've only come up with a handful of use cases for console IO:

1. logging
2. primary output to be read by the user or piped somewhere else, e.g. ls
3. text UI, from simple prompts all the way up to https://github.com/jtdaugherty/brick

Anecdotally, I think I mostly abuse putStrLn for logging, and I don't use a logger because of laziness and uncertainty about which is the one true logger.

from rio.

Somewhat tangential, but I've cultivated the habit of reaching for Debug.Trace when I'm feeling abusive. Much easier to notice and clean up after.

from rio.

In my application init code, I may need to output code to the terminal before I've setup a logger or my reader environment. #34 refers to an import of RIO.Text as a workaround, but I do not see any functions exported there that can write text to a terminal.

from rio.

I'm not sure if we exported the relevant functions previously, but in any event you would actually need Data.Text.IO. An alternative could be to use runSimpleApp for the initial output before the environment is set up. Another possibility (which may not be relevant) would be to create the log function immediately, use runRIO logFunc $ logInfo ..., and then incorporate that logFunc into your complete reader environment later.

from rio.

Thanks for your response! I was more just noting what I think is a valid use case for having terminal output capability in the prelude. These are all good workarounds, but I think a prelude replacement should probably provide this function unless you are really only targeting users who build production servers. Personally I would just re-export Data.Text.IO.putStrLn and call it a day, but I do understand you want to steer people towards better solutions for a lot of common use cases.

from rio.

Note that RIO does provide a suite of Debug.Trace reexports, marked as deprecated specifically to generate a warning (they're not actually going away). If your use case is quick and dirty debug output, this is preferable to putStrLn.

For dumping some info before/during initialization of the main app environment, I find runRIO logFunc $ ... to be perfectly serviceable, and it has the advantage of giving you a consistent output format.

One case I can think of where putStrLn has a clear advantage is when you are writing an interactive CLI app. But that is every bit as special-case as a web service IMO, and supporting it in the Prelude would subtly undermine the benefits of providing the trace and logging functions. It becomes an attractive nuisance when you don't have to think before using it.

from rio.

I just thought I'd leave an update, I ended up using Michael's suggestion to just setup the logger first and run the rest of my init code in RIO with the LogFunc env. This actually ended up cleaning up some code because I had to supply a MonadLogger instance when creating a Postgres pool anyway, and now everything logs consistently so I'm happier with it overall.

from rio.

Just coming across this as I was pulling in RIO for a new project and realized there is no putStrLn. Since there does not seem to be consensus yet here are my 2c - I think the use case of reading in bytes and writing bytes to stdout in a unix pipeline is quite common (e.g., text processing). For this use case I think that say is too heavy/restrictive, but I quite liked @chrisdone's suggestion of having some simple utility functions for writing to stdout #5 (comment), with additions like

hPutBytes :: (MonadIO io) => Handle -> Builder -> io () -- Put bytes to handle
hPutUtf8 :: (MonadIO io) => Handle -> UtfBuilder -> io () -- Put utf8 bytes to handle
putLn :: (MonadIO io, Display a) => a -> io () -- putUtf8 . display but also with a newline
-- putBytes, putUtf8, hPutLn, etc.

from rio.