Lizardsquid, maker of noises @lizardsquid@computerfairi.es

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...

@popefucker@cybre.space monoids aren't so important, but monads are significant because they're what allows for composable code with "side effects"

typically, we want to be able to compose functions together:

h = f . g

because this makes designing programs easier.

but when it comes to functions that have side effects (like writing files or displaying stuff on the screen), we want those to be isolated from other functions, because the *order* in which we do things is suddenly important

@popefucker@cybre.space there's so much more - feel free to ask me any questions about anything

@popefucker@cybre.space

* the equals sign works the same as in algebra - whenever you see the LHS, you can just replace it with the RHS (and visa versa)

* types are just sets - if you write a function, it takes elements from one set and returns elements of another set, for example:

isEven :: Integer -> Boolean
isEven n = case n `mod` 2 of
0 -> True
otherwise -> False

is a function that takes elements from the set of all integers, and returns elements from the set of Booleans.

@popefucker@cybre.space http://haskellbook.com/ is pretty good and starts from first principles, but costs money

http://book.realworldhaskell.org/ goes into a bunch of mathematical details later on.

those are both kinda generic, though, so I'll give you some specific stuff that might be useful to someone with a maths background in the next toot

hey sometimes I get too affectionate and snuggy, so if I ever make you uncomfy, I'm sorry.

and please... tell me, so I can improve