Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

List is a monad

alexyorke.github.io

Post reply on HN
Print view View original

171–180 of 187 posts

Re: List is a monad

#171

Post by recursive »

4ad wrote: post #165
recursive wrote: post #143

Earlier quoted context omitted.

Yes. If you don't already know category theory, learning it is hard. The terms on wikipedia seem to form a dense graph of links. It's hard to get a foothold of comprehension. For people that already know C++, or are at least familiar with this syntax, this is more useful than describing it in haskell syntax or category theory. There seems to be a chicken and egg problem regarding haskell and monads. Learning c++ may…

Learning category theory to the level of understanding monads should take half an hour at most, and would constitute real understanding of what a monad is, versus this C++ explanation which is handwavy even in terms of C++. C++ can't even encode monads accurately! But one doesn't even need to learn category theory. I assume that everybody has learned abstract algebra in high school, monoid, rings, groups, vector spac…

I learned none of those in high school or university. I did indeed fail for much more than 30 minutes to learn any of them from Wikipedia and other sources.

Over the years I've spent many hours trying to make any sense of monads with varying degrees of success. But mostly not.

Your assertions do not seem consistent with reality as I've observed it.

Re: List is a monad

#172

Post by cynicalkane »

chongli wrote: post #146
cynicalkane wrote: post #134

Earlier quoted context omitted.

What helped me grok the mathematical rigor is: If you have a series of monad operations that exist purely in monad world -- in Haskell, if your expression is parametric over the type of the monad -- you shouldn't have to worry about how you do it. This is what monads being categorically commutative ("a monoid in the category of endofunctors") buys you. You want to turn monad X into monad Y? Sure, just join, flatten,…

I think you mean associative. Neither monads nor monoids are commutative.

...Sorry, that was unclear. Monad-as-monoids being associative corresponds to certain categorical diagrams being commutative.

It's the concept of categorical commutativity that's what's useful. A collection of types and functions is "commutative" if every way to get from type A to type B yields the same result. It happens a lot in Haskell where most or all of the operations you're interested in commute with each other, which is how Haskell gets its reputation of "if it compiles it works". In particular, if you `fmap` or `bind` two commutative functions, the result becomes commutative, too.

Re: List is a monad

#173

Post by solomonb »

mnsc wrote: post #157
solomonb wrote: post #119

Earlier quoted context omitted.

Yes you're absolutely right. I had a bit of a brain fart moment here. If they were Applicative operations then you would not be able to use `liftM2`, not the other way around.

This is my fear when I think about doing actual in a team using a functional language. That there's an imbalance in understanding between participants in a team making all discussions about problem x into the pattern matchning problem y. Like "is this liftM2 or liftA2?" I've only had a couple of months of experience working with scala before the team switched to Java. The reasons were many but one of them was that th…

Well, I can't speak to your experience but in the case of liftM2 vs liftA2 I have never even seen liftM2 get used. Its more of a historical oddity that it is available.

Re: List is a monad

#174

Post by t43562 »

empath75 wrote: post #169
t43562 wrote: post #81

Another tutorial which makes monads about 100x more impossible to understand for me by relating them to something else and describing all the weird ways that they are NOT that thing. IMO if you already have it, this will be a lovely comparison full of insight, but if you haven't then it's full of confusing statements. IMO what they are is utterly unimportant, except to mathematicians, and what you can do with them is…

The reason that the explanations are all in Haskell is that Haskell is the only language that is reasonably popular that implements monad and calls it a monad, and 90% of the people looking up "What is a monad" are trying to learn Haskell.

Yes, you're doing 2 difficult things at the same time - a new language and a new concept. IMO it would be great to just have the concept to deal with.

Re: List is a monad

#175

Post by tome »

bjourne wrote: post #158
tome wrote: post #63

Earlier quoted context omitted.

It's not about what a monad can do, it's about a property of the language: referential transparency. Haskell has referential transparency, Python doesn't. That's a technical condition but here's a simple consequence: effect typing. In Haskell you can know what possible effects an operation has from its type. Here's an example from my effect system, Bluefin: foo :: _ => Exception String e1 -> State Int e2 -> Eff es Bo…

Those annotations create a compile-time enforced typological relationship between the input and output values of the function. Python doesn't have mandatory type-checking so it can't do that. But parent wasn't referring to type-checking. They claimed monads have expressive power unavailable in other languages.

> Those annotations create a compile-time enforced typological relationship between the input and output values of the function. Python doesn't have mandatory type-checking so it can't do that

Python doesn't have (mandatory) compile time type checking, no, but in principle a dynamically typed language could still be referentially transparent, and then it would (or at least could) still be the case that the only effects that a particular operation can perform are those arguments that are passed into it.

> But parent wasn't referring to type-checking. They claimed monads have expressive power unavailable in other languages.

That's true. But think of other syntax sugar like async/await. That comes for free in Haskell with monads and do notation.

Re: List is a monad

#176

Post by tel »

kevinventullo wrote: post #108

So I come at this from a math background but I’ve always found these explanations to be overly complex. In the parlance of C++, I think of a monad as a template class T with the following properties: 1. For any class X, there is a canonical method F: X -> T 2. For any class X, there is a canonical method G: T > -> T . 3. For classes X and Y, and any method f: X -> Y, there is a corresponding method “T ”: T -> T . ———…

Yeah, that's correct. You also often see it as having that for any method `X -> T` there's a corresponding method `T -> T`. Or you can have that for any two arrows `X -> T` and `Y -> T` there's a composed arrow `X -> T`. All are equivalent.

Re: List is a monad

#177

Post by Tainnor »

brooke2k wrote: post #5

As far as monad tutorials go, this one seems quite good. I like the categorization of monads between "containers" and "recipes". However, I personally think that monad tutorials tend to give people the wrong impression and leave them more confused than they were before, because they focus on the wrong thing. A monad is not a complex concept, at all. IMO a more useful way to present the topic would be with one separat…

> In my experience, people new to Haskell focus way too much on getting the "a-ha" moment for monads in general, [...]

I feel this is true in general for mathematics (and therefore by languages whose design is heavily inspired by maths). A lot of people not familiar with university-level maths think that they need to understand what some mathematical concept "really means", but modern mathematics is a structural science. It looks at things that have entirely different semantics (symmetries, conservation laws, integers, matrices, Rubik's cubes, ...) and noticing that they all have the same structure (they're all groups) and therefore we can say something about all of them simultaneously.

That doesn't mean that intuition is useless. Once you have thoroughly understood what makes a group a group or a vector space a vector space, it's totally normal to e.g. consider a space of functions and think of them in your head as if they were arrows in a Euclidean space (the analogy breaks down at some point, but it can carry you a certain way). That's also why it's fine to think of a monad as a container or as a burrito or whatever once you've actually understood the concept. But you can't really short-circuit this process in my opinion.

Re: List is a monad

#178

Post by Tainnor »

jerf wrote: post #53
bjourne wrote: post #38

Earlier quoted context omitted.

What can a Haskell monad do that a Python class cannot? 99% of all monads I've seen only facilitate local state manipulation.

It can do it type-safely. Monad is a weird type that a lot of languages can't properly represent in their type system. However, if you do what dynamically-typed scripting languages do, you can do any fancy thing that Haskell does, because it is weakly typed in this sense. (The sense in which Python is "strongly typed" is a different one.) What you can't do is not do the things that Haskell blocks you from doing becau…

> Monad is a weird type that a lot of languages can't properly represent in their type system.

While true, a lot of FP-inspired libraries in the majority of languages that don't have HKT will just implement one or several specific monads as well as the common operations on them. This creates some redundancy and slight inconsistency, but often the shared vocabulary is still strong enough to carry around expectations more or less, even if it's not explicitly enforced by the type system. That's how you can have sequence(): List> -> Either> in e.g. Kotlin, for example.

Even in Scala, where you actually can define a monad typeclass (trait), there are very popular libraries like ZIO that effectively give you a monad without actually adhering to any Monad trait. I believe they do this for type inference reasons.

Re: List is a monad

#179

Post by wsve »

danieltanfh95 wrote: post #114
polygot wrote: post #72

Earlier quoted context omitted.

Hi, I completely agree. "A" list isn't inherently a monad, and that is where my metaphor starts to fall apart a bit (my post title furthers this issue.) I can clarify this earlier in part 1 or 2 instead of in to-be-written part 3.

Its a harmful metaphor and clickbait title.

This seems harsh to the point of being untrue...

Re: List is a monad

#180

Post by kevinventullo »

tel wrote: post #176
kevinventullo wrote: post #108

So I come at this from a math background but I’ve always found these explanations to be overly complex. In the parlance of C++, I think of a monad as a template class T with the following properties: 1. For any class X, there is a canonical method F: X -> T 2. For any class X, there is a canonical method G: T > -> T . 3. For classes X and Y, and any method f: X -> Y, there is a corresponding method “T ”: T -> T . ———…

Yeah, that's correct. You also often see it as having that for any method `X -> T ` there's a corresponding method `T -> T `. Or you can have that for any two arrows `X -> T ` and `Y -> T ` there's a composed arrow `X -> T `. All are equivalent.

Thanks for confirming; I wasn’t 100% sure what I wrote was equivalent to the `X -> T` definition, but I could see how you’d get one from the other using the unit/counit.
Post reply on HN