Lizardsquid, maker of noises @lizardsquid@computerfairi.es

@Ulfra_Wolfe wow...

I cleaned my room!

@Fenreliania *cuddles*

@turbodragon goodnight addison!!!! sleep well!!

I forgot to do this, I'm sorry

@popefucker@cybre.space side note: (>>=) is actually defined over *any* monad, not just IO

@popefucker@cybre.space sorry, I should have given you the type! It's kinda complex, so let me show you compose first:

(.) :: (b -> c) -> (a -> b) -> (a -> c)

this says "the compose function takes 2 arguments, a function from b to c and a function from a to b, and then returns a function from a to c"

>>= (which is called "bind") is:

(>>=) :: IO a -> (a -> b) -> IO b

which says "the bind function takes 2 arguments, something of type IO a and a function from a to b, then returns something of type IO b"

despite using haskell as my primary language for over 2 years, I have yet to use a monoid

woops, sorry for the long posts, I'll put them under a cw next time

@popefucker@cybre.space I don't know if that made sense?

@popefucker@cybre.space ...but now we can't compose it!

if we have:

reverse :: String -> String

we can't write

reverse (askAndResponse "what's your name?")

because askAndResponse doesn't return a String. It returns an IO String, which is something else

without monads, we'd be stuck - we can't use our results easily.

But if we make sure IO follows the monad laws, we can use the function >>= to compose:

askAndResponse "name?" >>= reverse

which makes writing code w/ effects easier

@popefucker@cybre.space for functions with no side effects (those that just take something and return something) it doesn't matter what order we do them in.

but functions that ask the user questions and wait for responses? the order matters!

so we have to wrap up whatever our function does in a higher order type:

askAndResponse :: String -> IO (String)

let's say this function displays whatever string we pass to it to the user, then waits for user response...