Monads are a way of encoding linearity in languages without linear types, like Haskell. Linearity allows you to have both purity and side effects.

>>51759264
explain more about this linearity
is it order of execution? its the only thing that comes to mind when talking about linearity

>>51759311
If a value is linear, it means you must use it once, and only once. So it's stricter than uniqueness in languages like C++ or Rust.

Formally, it admits side effects in pure functions, because the definition of purity is that every time you call a function with the same arguments, you get the same result (which includes the state of "the world"). If you can only call a function once with a given set of arguments, due to linearity, you can do side effects without breaking purity.

Informally, yes, it has to do with order of execution. If you have a linear value that represents the world, you have to thread it through IO calls like this:

// -o is the linear function space
readLine :: IO -o (IO, String)
writeLine :: String -> IO -o IO
main :: IO -o IO
main io = let
  (io, line) = readLine io
  in writeLine (toUpper line) io

Because you have to use each linear value once and only once, it is impossible to do things like duplicate or destroy the world state, and so functions that operate on that state must be called in an explicit order.

>>51759311
>>51759443
And the benefit of maintaining purity is that you could still use things like lazy evaluation without having to modify the code to explicitly use thunks, just like in Haskell.

And if you want to learn more about the relationship between linearity and effects, I suggest reading Philip Wadler's excellent paper, titled "Linear Types Can Change the World!".

While it simplifies concurrent reads by forcing them to be more or less strict, using techniques like type-level reference counting you can theoretically maintain complete laziness as well as concurrent reads. Dependent types then allow you to statically verify correctness of concurrent access even in the presence of runtime reference counting in things like shared pointers.

>>51759443
10/10

http://pauillac.inria.fr/~fpottier/slides/fpottier-2007-05-linear-bestiary.pdf

The amazing thing about linearity is that it blurs the lines between imperative and functional programming. You maintain the high degrees of safety and composability that come with functional programming, but you also get the ability to do the mutations and side effects that make imperative programming the performance king.

>>51759443
ohh, I see, it cleared up some things, although the wording is kind of confusing for a newb to programming like me
anyways, I didn't know main can have arguments
im confused too 'cause something like

main n = print n
main 3

doesn't compile

>>51759811
Well, it doesn't compile because main is the entry point of the application and requires the specific type of IO ().

The code I wrote isn't valid Haskell, by the way. That's just how it might look if it had linear types.

>>51759623
is that >>51759703?
also, yeah, I'll definitely read it
it sucks when you understand how monads work and applicatives and all that stuff, but can't see the big picture or understand why its important

how do I run an IO action over a container like Maybe, but still not wrap the result in a Maybe?

>>51760237
comonads

>>51759264
>>51759443
I'm high as shit and this is the first time I'm actually understanding monads.
It's like an object that contains your state and you perform functions on, right? Like you have your object and perform a function on it and you get a copy with updated state back.
Fuck, I'm fucking visualizing it even now.
>tfw finally getting it after working in haskell for like 2 years

>>51760870
what module?
what type class?

>>51761287
but what is a state
is it like a namespace in python, where there are local and global namespaces?

>>51760237
That doesn't really make sense.

>>51761287
Yes, that is one application of monads. As long as you have a functor, return, and join/bind, and they all follow the monad laws, you have a monad. There are lots of things that fit this pattern, so Haskell got special syntax that automatically desugars to binding. That's all there is to it.

>>51763420
>have a maybe containing an io
>want to run that io and do nothing else
fmap

>>51763603
You mean something like this?

maybeDo :: Maybe (IO ()) -> IO ()
maybeDo Nothing = return ()
maybeDo (Just action) = action

>>51763622
I knew about patern matching, but I just wanted to know if there was any other way other than creating a new function
also, why write type declaration for every function?
is it customary to do it in haskell

>>51763668
I usually write the type declaration for every top-level expression.

When I write functional code, I tend to think about the type first, which then immediately disqualifies every implementation that doesn't fit the type (they wouldn't be correct anyways, of course).

The other neat thing about types is that you can simply search for a type in Hoogle, and it will spit out the library functions that either match or are close to the type you give it.

>>51763695
thats fair, but after a while, don't you just automatically think about types in your head?
doing what you do is great advice for newcomers, but it seems after a while, it just becomes tedious if you just write code for yourself

>>51763893
Writing type declarations has never seemed tedious for me. I don't think there's a single drawback to writing them, at least at the top level. They're documentation and correctness checks in one package.

Also, once you start getting into certain Haskell extensions, inference becomes incomplete and you will have to sometimes write the types anyways.

>>51763603

maybe (return a) id io

>>51763893
It might be nice to have type inference while you're writing but ultimately if you plan to maintain the software you want to write types to keep you and anyone else who has to touch the software later on sane.