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

141–150 of 187 posts

Re: List is a monad

#141

Post by Dylan16807 »

tome wrote: post #84
AnimalMuppet wrote: post #78

Earlier quoted context omitted.

But historically, wasn't there a fair period of time between Haskell insisting on referential transparency (and therefore not allowing traditional mutable state) and monads being introduced as a way to deal with it? That was my understanding of the history. And if so, then it seems fair to say at least that monads were a way to get around the limitations imposed by a desirable feature of the language...

> But historically, wasn't there a fair period of time between Haskell insisting on referential transparency (and therefore not allowing traditional mutable state) and monads being introduced as a way to deal with it? That was my understanding of the history. Yes, although there were solutions in the meantime. I/O was performed in the original version of Haskell through input-output streams and continuation passing s…

> Would you say that function calls in C were a way to "get around the limitations imposed by not allowing global jumps"?

If C had started with a rule against global jumps, and only figured out function calls later, then yes I would say that.

Re: List is a monad

#142

Post by instig007 »

PaulHoule wrote: post #124
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…

I came to the conclusion that a List is a good generic data structure, for instance in cases where the cardinality is supposed to be 0..1 it is often less trouble than a nullable scalar or an Optional and you have cases where you’re going to get a list anyway such as if you are querying a relational database. (Often people write awkward code to turn that result into a nullable/Optional and then more awkward code to t…

yes, exactly, not sure why your comment was downvoted. Also, generally it's not cardinality of 0..1, it is `[]` vs `xs:[]`, that is - either empty, or a multitude of values, where 1 is a specific instance of the multitude (singleton).

Re: List is a monad

#143

Post by recursive »

4ad wrote: post #111
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 . ———…

So you think that a monad which is an object with a simple definition in category theory is better explained in terms of C++? I would agree that most of these articles about monads are bad. Just study the definition, then study what you can do with monads, it's not that hard.

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 be harder or easier than category theory. I'm no sure, as I don't understand either one of them. But this syntax makes more sense to me than something expressed in terms of category theory vocabulary.

Re: List is a monad

#144

Post by instig007 »

nemo1618 wrote: post #31

I think this adds more confusion than it removes. A list is not a monad. A list is a data structure; a monad is more like a "trait" or "interface." So you can define a List type that "implements" the monad interface, but this is not an inherent property of lists themselves. That's the sense in which a list "is a" monad: the OOP sense. Haskell's List monad provides a model for nondeterminism. But that certainly isn't…

> A list is not a monad. A list is a data structure; a monad is more like a "trait" or "interface."

You operate with things that are bound to PL notions of specific languages. Instead, consider that list isn't a data structure, it's an abstraction that defines a multitude of position-ordered values. The multitude of position-ordered values called "list" is a presented entity of "monad", because it can be used as a valid input for a monadic computation defined consistently (in terms of the monad laws).

Re: List is a monad

#145

Post by Kranar »

kevinventullo wrote: post #117
Kranar wrote: post #112

Earlier quoted context omitted.

This is like explaining chess by simply stating the rules. Like sure explaining the rules of chess is important but only knowing the rules provides for nothing more than a superficial understanding of a topic.

I mean if someone is learning chess for the first time, then yes you should start with the rules rather than jumping right into waxing philosophic about positional strategy to show off how smart you are.

Yeah I am aware that most teachers, like another commenter said, do teach math just by spitting out the rules and then people memorize them and sure who am I to argue against that. It's not how I learned math and most people I know who are well versed in math including those with PhDs (and working as a quant I am fortunate enough to work with many) also don't really learn things that way either...

When I taught my daughter chess at the age of 5, I did not teach her by laying out the rules and in general when I teach people anything, I don't start by emphasizing rules. Rules are often the least interesting part of any subject and I find rules are much easier to learn once a sufficient amount of motivation has been given first, and then we get to a point where we use rules to crystalize our intuition and express rigorously what we've come to learn. The rules are the end result of learning, not the starting point.

With chess, I taught my daughter by simply playing a simple game where I had a queen, and she had one king and two pawns, and her goal was to get one pawn across the board and my goal was to stop her.

The king and pawns are arranged so that with perfect play she is guaranteed a win, and eventually she learned the pattern that allows her to always win. I then switched it up so she gets the queen and I get the king/pawns but I arrange the king/pawns so that I will always lose if she plays perfectly.

After this, I added more pawns for white and a bishop for black. The motivation for adding these pieces is that to play perfectly and always win as white, you need to learn how pawns define the physical structure of the board, making walls and allowing for control over certain parts of the board, but this also comes at the cost of introducing clutter and making it hard for the king to maneuver.

After these principles are learned, then I introduce the knight, because the knight can jump over walls and isn't as burdened by clutter. I don't just put a knight in the game out of nowhere and make her memorize how it moves... by the time the knight is introduced, it feels natural to want a piece that has better maneuverability over the extra pawns.

And so on so forth... each piece is introduced with some kind of motivation for why it exists. It's not just there for the sake of existing because of some rule that you just need to memorize. It exists because it adds some kind of flavor and richness to the game and you end up absorbing the rules rather than just memorizing them.

Now I'm dwelling a bit on chess here... but the principle applies to programming as well. I don't think if you ever just listed the rules you did as a means of teaching someone about monads anyone would ever come to appreciate why these rules matter or why they should waste any time learning them and in fact I am fairly confident that this kind approach to teaching people functional programming is why it's taken so long for mainstream languages to appreciate these features and adopt them.

Re: List is a monad

#146

Post by chongli »

cynicalkane wrote: post #134
aeonik wrote: post #29

Earlier quoted context omitted.

I think you are right. I don't think I've fully mastered the concept yet, but what you are saying resonates with me. I've been trying to grok monads for almost a decade. More and more I'm beginning to realize how "mundane" the concept is, and the usefulness really is just that specific pattern of mundanity. Similar to pipelines on Linux, they are pretty basic, but their ubiquity and their use in composing unrelated t…

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.

Re: List is a monad

#147

Post by throwaway290 »

lordgilman wrote: post #120
agnishom wrote: post #118

Somebody is keeping a giant list of Monad tutorials, right?

Yes, and we are approaching peak monad tutorial https://wiki.haskell.org/Monad_tutorials_timeline

So in the golden age of the internet we had the highest rate of monad tutorial growth. Churn them out, bring back the good times

Re: List is a monad

#148

Post by bdangubic »

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…

with this comment you joined a list of seven million devs that have written a monad tutorial :)

Re: List is a monad

#149

Post by still_grokking »

skybrian wrote: post #110
IshKebab wrote: post #34

Earlier quoted context omitted.

This is a good explanation: https://users.scala-lang.org/t/what-is-a-monad-in-scala/4169 It's like... what would you call all types that have a .write() method? Writable right? What would you call all types that have a .dispose() method? Disposable. What would you call all types that have a .flatMap() method? Monad obviously.

That’s because flatMap() is a good name for a particular list operation, but it’s not generic enough to be a good name for the corresponding monad operation. I’m not sure there is a good name for the monad operation. Sometimes it’s called ‘bind’ but what does it bind? I suppose you could call it ‘then’ like when working with Promises.

Scala's new effect library Kyo just uses `map`. See:

https://getkyo.io/#/?id=the-quotpendingquot-type-lt

All pure values are automatically lifted into the Kyo monad, so `map` is effectively `flatMap`.

From the linked docs:

> This unique property removes the need to juggle between map and flatMap. All values are automatically promoted to a Kyo computation with zero pending effects, enabling you to focus on your application logic rather than the intricacies of effect handling.

In the end it makes a lot of sense I think. What you do is manipulating values inside some wrapper. Whether this wrapper is a monad or not should not matter. Just do something with the value(s) inside, and that's mapping.

Re: List is a monad

#150

Post by timewizard »

nine_k wrote: post #86
stronglikedan wrote: post #58

Earlier quoted context omitted.

After reading your comment, I've made it my mission to understand it. Although I have no idea what you're talking about, you make it sound intriguing.

To get a minimal idea, you can think about a monad as of a parametrized class: M . Its functioning follows "monad laws" that allow you to do certain things with it, and with the value(s) of T wrapped my it. In particular, you can always "map" the values: M ::map(f: (T1 -> T2)): M List ([1, 2, 3]).map(x => toString(x)) == List (["1", "2", "3"]) You can always flatten the nested structure: M >::flatten(): M // [["a", "…

> immediately transforms into

Minor quibble, "can only be resolved as". The runtime absolutely holds Promise>'s.

Post reply on HN