Und auch dieses Video ist wirklich sehr sehr gut gelungen. Unter jedem Video hört man die Leute meckern wie schlecht es erklärt sei und das stimmt auch. Außer hier. Vielen Dank für die Haskell-Reihe!!!
Beware of over-monading :-) . Often the Applicative type (which is the supertype of Monad) can be used leading to more concise code, e.g. monadd = liftA2 (+) Another advantage is that this expression doesn't impose a certain evaluation sequence.
@@Parapascal No, join = (>>= id) so join :: Monad m => m (m a) -> m a. It removes one layer of monad wrapping for "double wrapped" values. For lists, it's also called flatten with the signature [[a]] -> [a]. On the other hand, (>>) :: Monad m => m a -> m b -> m b
Any example for associativity? m >>= (\x -> k x >>= h) = (m >>= k) >>= h , is this what you mean? f1 x = (Just x >>= (\x -> Just x)) >>= (\x -> Just x) should always be equal f2 x = (Just x) >>= (\x -> Just x >>= (\x -> Just x)). What is the point? We still have to evaluate it left to right in both cases in this example. Any benefits of having this?
Think of a large expression of many maybys used with the bind operator. A single Nothing results in the whole computation to be nothing, due to associativity. That's something we could optimise for!
What is the Monad(m::*->*) ?? Specifically what is the (m::*->*) ? Do it means that monad is some kind of function ? Does it means m is a constructor ?
I wanted to use the λ x . x instead of >>= operator. x and λ - function should have the type Maybe. How can I do this? I think, serialization of Parameters can be done of currying. I am making my own functional programming language and I wanted to build an operating system with it, where it is possible to built a memory management. I wanted to do it with monads with functions in operator notation and not infix notation. Most of the functions should be implemented by the λ-calculus. The λ-calculus is very restrictive and direct access to storage is not allowed but it should be done. I think monads should be a solution for this problem. But I am not sure.
Ok, thank you! And using a let binding inside a do notation, would be evaluated equally, as if we would define it using "where" when using >>= . That's then why let bindings are evaluated lazyly, nice.
Stephen Edwards' video th-cam.com/video/_Gk_lwhJMzk/w-d-xo.html does an excellent job of explaining monads to the less technical user. Then we can take the more commonly know async functions and promises in Javascript: how we go from * I know this is not an exact analogue f().then(x => f(x)).then(x => h(x)).then(x => k(x)).catch() to { let a,b,c,e try { // cf. Haskell's do a = await f() b = await g(a) c = await h(b) await k(c) } catch( e ) { console.log("Exception",e) } } and then explain how Haskell's do is a case of running one function and sticking its output into another, until we finish or an error occurs. (the 'and then... and then...' idea from Stephen's video) Only when the concept is understood should we bring in concise notation and abstract definitions.
Start at video number one. Or start with Learn You A little Haskell For The Greater Good. It’s free and online courses work for anybody at any level and prior experience.
I find it easiest to use IO Monad as example. This is how I understand it, it might not be completely accurate, but it's enough to give you some hint of how it works. getLine :: IO String putStrLn :: String -> IO() lol ::IO lol = getLine >>= putStrLn alternatively lol = do trololol >= "extracts" the value out of the monad and pushes it into a function. If you want to chain these you will have to have functions that goes from "regular value" to Monad of "regular value" So signature becomes foo :: Whatever -> IO Whatever foo2 :: Whatever -> IO Whatever foo3 :: Whatever -> IO Whatever bar :: IO Whatever bar = foo >>= foo2 >>= foo3 The >>= in this case turns IO Whatever into a Whatever and shoves it into a function. Whatever can be a string or any other type. You can also do it like this bar = do x
Monads are not an easy topic! A big problem that occurs with monads is that you can interpret them in many different ways. In this video I interpreted them as "containers for values with predefined operations" yet others interpret them as "encapsulated computations" and others might have another interpretation. Depending on the use-case the interpretation also changes so it's a bit of a strange thing. ;)
Just keep trying. This is my tenth time reading or listening to a monad explanation and it was the bast for me so far. I finally get it. But need to do lots of practice in code to lock it in!!
After listening to this video without any of the visuals, I am only left with one question: What is a monad?
Best Monads explanation ever.
The first time that I (roughly) understand what a Monad is. And then the do notation from working with IO - light bulb moment!
Thanks.
Nice video!
One small detail and I'm nitpicking but the fail function is no longer part of Monad, it now lives in the MonadFail typeclass
Und auch dieses Video ist wirklich sehr sehr gut gelungen.
Unter jedem Video hört man die Leute meckern wie schlecht es erklärt sei und das stimmt auch. Außer hier.
Vielen Dank für die Haskell-Reihe!!!
Monadd was definitely worth it lol, these videos have all been really good so thank you!
Beware of over-monading :-) .
Often the Applicative type (which is the supertype of Monad) can be used leading to more concise code, e.g.
monadd = liftA2 (+)
Another advantage is that this expression doesn't impose a certain evaluation sequence.
monadd = liftM2 (+)
with liftM2 from Control.Monad… so I'd not say more concise (but more general)
">>" is actually called "then".
Thank you. I thought it's called join. Confusing
@@Parapascal No, join = (>>= id) so join :: Monad m => m (m a) -> m a.
It removes one layer of monad wrapping for "double wrapped" values. For lists, it's also called flatten with the signature [[a]] -> [a].
On the other hand, (>>) :: Monad m => m a -> m b -> m b
Literally laughed out loud when you said “Right…That was worth it”
mind
"monadd" hahaha
Now please also explain how flatten is equivalent with bind.
flatten = (>>= id)
bind f ma = flatten $ fmap f ma
5:45 lol. All the "maybe" jokes were fun too 8:11
Now please explain the State Monad :)
How about the State Monarch :D
Any example for associativity? m >>= (\x -> k x >>= h) = (m >>= k) >>= h , is this what you mean? f1 x = (Just x >>= (\x -> Just x)) >>= (\x -> Just x) should always be equal f2 x = (Just x) >>= (\x -> Just x >>= (\x -> Just x)). What is the point? We still have to evaluate it left to right in both cases in this example. Any benefits of having this?
Think of a large expression of many maybys used with the bind operator. A single Nothing results in the whole computation to be nothing, due to associativity. That's something we could optimise for!
@@philipphagenlocher Oooh, smart 🤠. Makes sense.
@@geogreenmanu monads and maybe were literally star-destined to meet at the club.
You're a legend
What is the Monad(m::*->*) ??
Specifically what is the (m::*->*) ?
Do it means that monad is some kind of function ?
Does it means m is a constructor ?
The notation * -> * is called kinds it's basically can be considered types of types it means monad expect a type which itself expect a concrete type.
What was the at 9:05? I don’t think you explained what the instance is and I didn’t understand anything else there
It's an instance of a type class, the subject of video number 13 in this series.
I wanted to use the λ x . x instead of >>= operator. x and λ - function should have the type Maybe. How can I do this? I think, serialization of Parameters can be done of currying. I am making my own functional programming language and I wanted to build an operating system with it, where it is possible to built a memory management. I wanted to do it with monads with functions in operator notation and not infix notation. Most of the functions should be implemented by the λ-calculus. The λ-calculus is very restrictive and direct access to storage is not allowed but it should be done. I think monads should be a solution for this problem. But I am not sure.
I think my third eye opened when I realized that maybeadd can be written as
maybeadd mx my = (+) mx my
mon add for some reason i mixed french and english and understood it as my add LOL
Can u help to test a function that returns MaybeT type
Brilliant ❤!
Monadd (with 2 D's) got me good 🤣
Thanks so much
Took a few watches to get this one down lol
Is what = in the monad?
Correct! (This is true since "x >= (\x -> ...")
Yes.
do
x = \x -> getLine >>= \y -> return $ x ++ y
So it's literally using >>=.
Ok, thank you! And using a let binding inside a do notation, would be evaluated equally, as if we would define it using "where" when using >>= . That's then why let bindings are evaluated lazyly, nice.
@@Daniel-ws9qu Pretty much, the let binding is just inserted in between like this:
do
x >= \x -> let s = x ++ "? Cool!" in purStrLn s
Philipp is da real mvp
Subscribing just for the joke
Stephen Edwards' video th-cam.com/video/_Gk_lwhJMzk/w-d-xo.html does an excellent job of explaining monads
to the less technical user.
Then we can take the more commonly know async functions
and promises in Javascript: how we go from
* I know this is not an exact analogue
f().then(x => f(x)).then(x => h(x)).then(x => k(x)).catch()
to
{
let a,b,c,e
try {
// cf. Haskell's do
a = await f()
b = await g(a)
c = await h(b)
await k(c)
} catch( e ) {
console.log("Exception",e)
}
}
and then explain how Haskell's do
is a case of running one function and sticking
its output into another, until we finish or an
error occurs. (the 'and then... and then...' idea from Stephen's video)
Only when the concept is understood should we bring
in concise notation and abstract definitions.
perhaps it would have been better if you started with a general intuition!
If anyone understands this I salute him.
Start at video number one. Or start with Learn You A little Haskell For The Greater Good. It’s free and online courses work for anybody at any level and prior experience.
I find it easiest to use IO Monad as example.
This is how I understand it, it might not be completely
accurate, but it's enough to give you some hint of how it works.
getLine :: IO String
putStrLn :: String -> IO()
lol ::IO
lol = getLine >>= putStrLn
alternatively
lol = do
trololol >= "extracts" the value out of the monad and pushes
it into a function.
If you want to chain these you will have to have
functions that goes from "regular value" to Monad of "regular value"
So signature becomes
foo :: Whatever -> IO Whatever
foo2 :: Whatever -> IO Whatever
foo3 :: Whatever -> IO Whatever
bar :: IO Whatever
bar = foo >>= foo2 >>= foo3
The >>= in this case turns IO Whatever into a Whatever and
shoves it into a function.
Whatever can be a string or any other type.
You can also do it like this
bar = do
x
@@torarinvik4920 Thanks a lot bro. You cleared my concept of >>=
@@torarinvik4920 BTW. Are you haskell developer. Did you earn anything through haskell ever?
@@maheerali531 My pleasure :)
just another video that i watch that i hope to understand monad with it but i didnt ,sorry it is probably me problem
Monads are not an easy topic! A big problem that occurs with monads is that you can interpret them in many different ways. In this video I interpreted them as "containers for values with predefined operations" yet others interpret them as "encapsulated computations" and others might have another interpretation. Depending on the use-case the interpretation also changes so it's a bit of a strange thing. ;)
@@philipphagenlocher thanx very much
It's taken me at least three goes. You'll get there.
Just keep trying. This is my tenth time reading or listening to a monad explanation and it was the bast for me so far. I finally get it. But need to do lots of practice in code to lock it in!!
That's just a monoid in the category of endofunctors
Take my value. Please. 😉
5:57 I genuinely laughed but for a different reason
MONADD
5:45 moan add
5:46 rofl
monads don't exist, silly