Just what on earth is the freaky fellow in pic related?

Why not? Haskell is c++ of functional programming

I think the simplest example is the 'Maybe' monad, I'll try to explain.

Maybe is defined as:
data Maybe a = Just a | Nothing
Notice how 'a' is generic, like List in imperative languages.
This means that the maybe monad of say, 'Maybe Integer' can only have the sum types 'Just Integer' or 'Nothing'. This becomes useful, for instance, when you are chaining the 'Maybe' monad.

Say we have multiple functions:
funcA :: Int -> Maybe Int
funcA x = Just $ x + 1

funcB :: Int -> Maybe Int
funcB x = Just $ x * 2

funcC :: Int -> Maybe Int
funcC x = case x of
4 -> Nothing
_ -> Just x

The first function just takes an 'Int' and adds one and returns a 'Just Int'.
The second function takes an 'Int' and multiplies it by two and returns 'Just Int'.
The third function takes an 'Int' and checks if it is 4, if it is 4, then we return 'Nothing', otherwise we return 'Just Int'.
Now, the actual fun part is chaining monads, so lets chain them in a new function.
run :: Int -> Maybe Int
run x = funcA x >>= funcB >>= funcC

Here we take an Int and maybe return an int. funcA gets called with x as the argument, then the result of funcA gets passed as argument to funcB and lastly the result of it gets passed to funcC.
Now let's run this function with 1 as the first argument and see what happens.
main :: IO ()
main = do
val

Also wanted to add this last bit but it was refused:

This is roughly speaking, what the monad above is doing:
result = funcA(x);
if(result == NULL) return NULL
result = funcB(result);
if(result == NULL) return NULL
result = funcC(result);
if(result == NULL) return NULL
return result;

>Why the hell anyone would want this continues to mistify me

So you're saying you understand how monads work but not why you would want to use one?

Well, can you look at all the code you're writing and remove them? For example, try doing all your IO and error handling using only the functor/applicative/etc. instances for IO and Maybe

Thanks for the post.

So my prognosis was confirmed. It's literally just doing a bunch of things and returning nothing if any of them don't work.

I guess the number of functions just hinge on the number of >>=s and every monad example happens to use 3 because it's the simplest point where that becomes worth using a monad (?)

I'd say I still have a good few months of dicking around with Haskell and category theory before I begin to grasp why this is useful

Attached: 1550231600555.jpg (600x800, 274K)

>So you're saying you understand how monads work but not why you would want to use one?

As of I now I understand the first part.

I think I'll be using Haskell for a few months before I begin to actually understand why this is useful.
You can explain what a function is to someone that's never done calculus or computer programming, but until you actually do it you don't really get why anyone would want it.

Unless someone can invent a real-world analogy for what a monad would be used for.

Attached: 1550457154311.png (360x230, 39K)

Be careful about overgeneralizing your understanding though. "Doing a bunch of things and returning nothing if any of them don't work" is a rough description of chaining operations in the Maybe monad, but that's just the Maybe monad. Other monads like IO or the basic list [] have nothing to do with error conditions or anything like that. There is an abstract pattern that these all follow, which has to do with manipulating layers of structure and the values inside them, so you'll want to understand what makes the Maybe monad, the IO monad, and the list [] monad all cases of the same abstract thing

If could write an equally illustrative post for one of these other common monads that may help

Lets look at an IO example, because doing things in the real world is fun. Lets read some files.

For this we have a function in System.IO which you can import:
readFIle :: FilePath -> IO String

We don't just want to read a single file, no that would be too easy, let's read multiple files. You should know about the 'map' function by now, if not, then you should learn it because it is used a _lot_ in Haskell. For this we have the function 'mapM' which maps over _M_onads, that's what the M in 'mapM' stands for.
mapM :: Monad m => (a -> m b) -> t a -> m (t b)

So lets say we wanted to give Haskell a list of files and make it print every files contents, how would we do this with 'readFile' and 'mapM'?

Let's do some basic string replace to figure out what the non-generic types are for mapM. So we know from 'map' that we give it a function and a list and then it returns a list of the functions' results. 'mapM' takes a function as the first argument which returns 'm b' (doesn't this look familiar?) and the second argument which is 't a'. 't' is list in this case, because it is also a monad. So 'a' must then be our file names.

Here's what we've got:
mapM :: (FilePath -> IO String) -> [FilePath] -> IO [String]
In plain english: give me a function that takes a filepath and returns an IO String and a list of filepaths, and I'll call the funciton on every element in the list and return you an IO list of Strings.

To print out the result, all we have to do is use bind '>>=' with print, because print will print basically anything (not going to go into the Show typeclass, that's for another day).

So, lets implement it:
import System.IO
main :: IO ()
main = mapM readFile ["a.txt", "b.txt", "c.txt"] >>= print

Notice how we simply plug in readFile (FilePath -> IO String) as the function and give it a list of filenames (t a). The result is then bound (or shoved) to print.

Pretty neat how much we can do with so little code.

He looks so happy with those new implants so I just can't stand and I'm happy for him too!

As far as Haskell is concerned, monads are defined by this typeclass.
class Monad m where
(>>=) :: m a -> ( a -> m b) -> m b
return :: a -> m a
With the additional restriction that any implementation of these functions needs to obey the following laws.
return a >>= k = k a
m >>= return = m
m >>= (\x -> k x >>= h) = (m >>= k) >>= h
If you understand what everything here means, you understand what a monad is.

Hey sorry I jumped ship on this thread thinking it was over

Your posts are worthwhile, ty very much

I'll be back to look everything over, but I really should be sleeping right now.

Attached: NUkDon2mrprvieeBZ4_oTwyQPYM-1EieOJJO1WuWYrA.jpg (2048x2048, 560K)

A the monadic bind allows you to pick your next 'thing' depending on the 'things' that happened before. Consider reading a line of user input and printing it in upper case.

getLine >>= \string -> PutStrLn (toUpper string)

Here the first monadic thing is getLine, and the next is PutStrLn something. Whithout >>= you cant pick that that something according to some other monadic value. If you try to implement this little functionality without using any monad specific functions and using only methods of Applicative for instance (I recommend doing this), then you'll experience the impossibility and really understand why you'd want bind.

Those are big breasts.

Oops, that should be (map toUpper string) obviously.

I can't focus on the merits of combinatory logic with those tits in view

I'm curious, what are the differences between monads and promises?

Promises are a kind of monad.

And not unlike monads, when you begin using these, you should know you really are on the wrong path and you may start thinking about using a technique less convoluted to achieve the same result.

Such as?

Why doyou need monads when everything can be written in assembly anywaY.

Coroutines at best. Otherwise, a request-reply model.

Coroutines can be implemented trivially as monads. Actually considering the relationship between continuations, coroutines and monads they're possibly best implemented as monads.

I don't care how they're implemented. Most languages that implement coroutines don't give a flying fuck about monads and will simply use jump and stack push/pop instructions. That's all.
Tell me how would you implement monads in machine code?

>Tell me how would you implement monads in machine code?
With two functions, just like in a high level language. Is that supposed to be a challenge?

That's already too much.

> Why the hell anyone would want this continues to mistify me.

Do the monad challenges to find out why.
mightybyte.github.io/monad-challenges/
They're difficult, though. Don't give up!

"Monad" is an interface. There's no actual code associated with the concept of "monad", except if you count generic monad combinators under type erasure.

The reason to implement the monad interface for coroutines (or anything else where it fits) is because 1. you won't need special syntax if you have generic monad syntax and 2. you can use generic monad combinators with them.

>muh burritos
Fun fact: FP stands for Faggot Programming

>two functions
>too much

Attached: file.png (680x848, 304K)

data Maybe a = Just a | Nothing
so is a monad specifically any type that has both a value constructor which takes a parameter and one that takes no parameter?
what exactly separates this from
data Bool = True | False
if anything?

>so is a monad specifically any type that has both a value constructor which takes a parameter and one that takes no parameter?
Not even close.

Maybe is just an example of a monad. A monad is defined, as far as the language is concerned, in these terms.
For Maybe, those functions are defined as follows.
instance Monad Maybe where
Nothing >>= f = Nothing
(Just x) >>= f = f x
return = Just

I'm not sure if I quite understand the syntax on that last constraint.

Which part of the syntax is confusing you?

why does the trapezoidal function f return 2 boxes instead of 1, and why are the boxes broken and dropping into a third box?

1. Put things in a monad
2. Monadic bind
3. ???
4. Profit!

what's "pure"?

it would be better if the diagram showed the implication of the second argument of bind
a -> m b

the function taking circles and returning squares, for example; and then wrapping them into the original kind of structure.

of course he is happy, traps are basically incels gaming the system

for you

it's there to wrap the Maybe Int of run 1 into the IO monad
pure $ run 1 :: IO (Maybe Int)

i thought "return" was the thing that put things into a monad, is it the same as return or do they do different things?

I always suspected haskell was a meme language but holy shit

Pure and return mean the same thing. The only reason they are distinct functions is because of legacy cruft.
(pure is an Applicative function while return is a Monad function. Monad was made a subclass of Applicative at a later time.)

same thing, you can even see how return is defined as pure
hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.Base.html#Monad

another way of writing that main would be
main = return (run 1) >>= print