65: Getting Haskell I/O - JSToElm
All Episodes

65: Getting Haskell I/O

We have made it to the beginning! With a solid understanding, or at least a better understanding we are ready to tackle I/O, aka side effects!

It as dawned on me as I have tried to find a better way to number, categorize this episodes, that each unit has about a dozen lessons. So Unit 4, that we’ll cover now are lessons 20-23.

IO in Haskell

  • avoiding state is the one of the key tenants of Haskell.
  • So how does Haskell rectify that tenant with the need to acutally makes changes to the outside world? like files, network requests, or other types of interaction
  • You should know this by now. Types!!

Special parameterized type

  • name? you guessed it, IO
  • Any value in IO context MUST stay in this context.
  • This prevents it from clouding up or haskell environment of purity.

    • For refresher, when I say purtity, what I mean is that it upholds referential transparency and doesn’t change state. Like a pure function.
    • IO makes it impossible to use values that are from IO in pure functions where, that function is not expecting to get polluted values that can’t really be trusted.

PSA Why writing every example is so important.

  • Even as I write out the samples I had to search for the following

    • loading a file into ghci
    • run and eval a .hs file
    • Data constructor is not in scope?

      • oh i was missing a second colon in the main type definition
    • Main was uppercased.
    • build random, not included in the main lib since 7.2

      • had to stack install it
      • then built it, tried to stack exec it, but I’d built it with ghc, so I had an executable, once i realized that i could just ./ call it. 🙄
  • This process is the learning. I know how to do this in JS. bc I’ve done it a thousand times! This is your chance to put down the muscle memory to a new language.
  • Don’t know it, can’t quite remember that command? Try something ? anything. use -h so see if you can figure it out.
  • but DON’T DWELL on it. This can be toxic. You don’t want to be frustrated, you want learn it and move on. Keep that in mind.

We’ve seen new things

  • The IO () type. Which appears to be an innvoced function! NOPE

    • it’s return is an empty tuple! more in a bit
  • The do keywork
  • putStrLn does that return a value ?
  • And my favorite curveball, A backwords arrow <- from getLine

    • getLine returns not a String, but a String IO

IO

  • parameterized type. remember like Maybe?
  • Like Maybe, IO describes a context for their parameters rather than a container.

    • I’ve thought of Maybe as a container that until unpacked coulbe have a value or be empty. If I can find the drawning that I always think of, I’ll link it. It was a while ago when I got a taste for functional programming, without knowing, through Swift.
  • The context that IO communicated is that came from / originated from an input/output operation, NOT from a pure function
  • The context for IO is a lot broader than for Maybe. Where Maybe is a possible missing value. IO can have an endless list of problems. How to account for all of them? That why this context for these values exists!
  • It’s a way to separate the code that deals with these uncertains, and the code in our Haskell program where we rely on these certians to make particular assumptions with of course help from the compiler.
  • IO actions are not functions. I repeat, not functions. Just a tuple with with Zero elements.

putStrLn

  • returns nothing at all! hence the empty tuple on our IO, the nothing is our return value! 😵
  • the empty tuple is the best way to communicate the nothing/empty return value

    • Not nessary in Maybe because Just () is eq to Nothing
  • bc of this Main isn’t a function, it must return a value. So we refer to it as an IO Action that action being a side effect!

    • other IO Actions might return a value, but not take a init value or doesn’t always return the same value. whatever it might be, it will violate 1 of the 3 rules that that a function must follow in Haskell.
  • putStrLn is an IO Action gottcha!!
  • and since putStrLn is an IO Action for not returning a value, getLine does’t take a value, so it too is an IO Action too. Ah ha!!!

Resources

Get Programming With Haskell

I/O Tutorial

Follow

Published 10 Jan 2019

A show about learning Elm, Functional Programing, and generally leveling up as a JS developer.
JavaScript To Elm on Twitter