5

My question: Is there any advantage to using Haskeline's outputStrLn over putStrLn for writing to the screen in a terminal program?

Background:

I recently introduced Haskeline into my terminal app in order to leverage the line-editing UI of the getInputLine function. (This required some significant changes to my monad transformer stack.)

I've since noticed that Haskeline comes with outputStr and outputStrLn functions for output. Now that I've gone to the trouble of adopting the library, I'm wondering if I should also prefer these output functions as opposed to the standard putStr and putStrLn. This would require more refactoring given the different monads returned by the functions in question.

Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197
the-konapie
  • 601
  • 3
  • 10
  • 3
    I had a very quick look at the source and went a bit though the rabbit hole: it looks like it eventually calls `withCodingMode` to ensure the handle is in the right encoding and binary mode. The docs of `outputStr` say "Write a Unicode string to the user's standard output", which seems to confirm that suspicion. I'm not completely sure that's it, though. – chi Nov 30 '22 at 19:36
  • I don’t know about the internals of Haskeline, but I once had an issue where if I used `liftIO` with either `putStrLn` or its equivalent in terms of `getExternalPrint`, then output would not appear immediately, yet `outputStr` worked correctly. So I assumed it must be expecting a certain buffering mode, or commandeering the terminal to render the prompt/editor, and that I must use `outputStr`, but I didn’t investigate further. Maybe this is a question for the Haskeline issue tracker? – Jon Purdy Dec 02 '22 at 00:18

0 Answers0