The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

Andreas Reuleaux (7) [Avatar] Offline
OK, at the end of chapter 6 I have learned quite a lot about Idris and IO,
and have seen quite an impressive example (the data store, now refined).

However, if I am not mistaken: all the complete programs, that I have seen so
far, that involve IO, are examples of REPL programs (they use either repl or
replWith), ie. endless cycles of getting input from the user and giving back
answers (until the user explicitly quits the program).

While it's certainly worth knowing these kind of programs (and one can
learn a lot about IO along the way), REPL programs are rarely the
first ones I write when learning a new language.

I typically start out much simpler, with a program that gets some
input from the command line, like the example below (taking a recent
example from the mailing list: fibs, but many other examples one could
think of: Celcius to Fahrenheit or whatever). The point here is that
with getArgs one can build nifty little programs (that can be useful
in day to day work, and replace some shell scripts maybe). Maybe
something like this is worth showing in the book as well?

module Main

-- fibs : Stream Integer

fibs : Stream Nat
fibs = 1 :: 1 :: zipWith (+) fibs (tail fibs)

main : IO ()
main = do 
         (cmd::args) <- getArgs
         case args of
              []     => putStrLn "need an argument"
              (s::_) => putStrLn $ show $ take (cast $ s) fibs          
         return ()

Edwin Brady (66) [Avatar] Offline
Hi Andreas,
I've done it this way (sticking with repl/replWith early on) because there's a lot of new concepts to introduce at the beginning already, and the reader isn't necessarily expected to know about how Haskell deals with IO. I think it's best to leave the details of IO until it can be done properly.