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

131–140 of 187 posts

Re: List is a monad

#131

Post by chriswarbo »

ww520 wrote: post #24
pdhborges wrote: post #12

Earlier quoted context omitted.

If all monad instances work differently what is the value of the Monad interface? What kind of usefull generic code can one write against the Monad interface. Related: https://buttondown.com/j2kun/archive/weak-and-strong-algebra...

Here is an analogy. List is a container whose elements can be any type. There are general operations applying to a list, e.g. map, reduce, filter, find, etc. Any data type (int, float, or bool) of list elements can use these same operations regardless. It’s similar for monad. If you can provide a unit constructor to turn an object value into a monad value and a “map” operation that unwraps a monad value, applies a fu…

> a “map” operation that unwraps a monad value, applies a function to it, and wraps the result

It can be misleading to think of "unwrapping" a monadic value, since the monad interface does not support it. For example, there's no way to implement a function `List -> T` using monad operations; it requires something entirely separate (e.g. indexing into a List, in this case).

What monads do provide is `join`, which turns nested monadic values into flat ones, like `List> -> List`. Even this seemingly trivial example is interesting though, since there are many ways to "flatten" a List> into a List: we could concatenate (e.g. depth-first), interleave (e.g. breadth-first), diagonalise (to support infinite lists), operate on chunks at a time (e.g. iterative deepening), etc.

Re: List is a monad

#132

Post by petesergeant »

danieltanfh95 wrote: post #115

The obsession with trying to explain a monad ultimately stems from conflicting explanations and the inability to differentiate between a mathematical monad and monads implemented in software. Monads in software are just a standard API for any given type. That’s it. Theres no magic here. Just implement the standard and you have a monad. It grinds my gears seeing monad tutorial after tutorial using the wrong metaphors…

> Monads in software are just a standard API for any given type. That’s it. Theres no magic here.

I don’t think that’s helpful for people to understand _why_ monads though, and that’s generally what people are looking for.

Re: List is a monad

#133

Post by monkeyelite »

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…

Also formal mathematical objects aren’t always like real world objects. What’s a ring? It’s a thing with these properties

Re: List is a monad

#134

Post by cynicalkane »

aeonik wrote: post #29
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 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, return, bind in whatever way makes the type checker happy. Anything that only uses what's in the Monad typeclass must necessarily be a monad morphism, so if you're generic over your monads, you get that for free. And of course `fmap` and `bind` are required to be parameterized monad morphisms, so there's a lot you can get for free.

Re: List is a monad

#135

Post by instig007 »

jameshart wrote: post #122
moomin wrote: post #17

Earlier quoted context omitted.

Your basic problem is that your programming language can’t express the concept cleanly. You need what’s called “Higher-Kinded Types”. To give you a concrete example, in C# Func , List -> List Func , Task -> Task Func , Func -> Func Can’t be expressed using a generalisation. But in Haskell, you can write (Functor F) => Func , F -> F One of the biggest things that makes monads hard to understand is that the type system…

I'm sorry, I'm not sure I understand entirely what you are trying to express by Func , List -> List That said, in C#, you can write: List listA; Task taskA; Func func; List listB = from i in listA select func(i); Task taskB = from t in taskA select func(t); And if it can resolve a method on List called 'Select' that takes a Func that returns a List , and a method on Task called 'Select' that takes a Func that returns…

now write a single function that performs

  from x in xs select fn(x)
and define a signature for it where `xs` and `fn` are the only input arguments, so that it accepts both `listB` and `taskB` without a compilation error.

Re: List is a monad

#136

Post by jameshart »

instig007 wrote: post #135
jameshart wrote: post #122

Earlier quoted context omitted.

I'm sorry, I'm not sure I understand entirely what you are trying to express by Func , List -> List That said, in C#, you can write: List listA; Task taskA; Func func; List listB = from i in listA select func(i); Task taskB = from t in taskA select func(t); And if it can resolve a method on List called 'Select' that takes a Func that returns a List , and a method on Task called 'Select' that takes a Func that returns…

now write a single function that performs from x in xs select fn(x) and define a signature for it where `xs` and `fn` are the only input arguments, so that it accepts both `listB` and `taskB` without a compilation error.

Right, ‘some type that has a Select(Func) method available’ is not a thing you can express in C# generic constraints.

But I don’t need a function that does that, the language has syntax for it - I can just do that wherever I need it.

Re: List is a monad

#137

Post by monkeyelite »

Kranar wrote: post #112
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 . ———…

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.

Yes, this is how you learn math. It helps to pair definitions with examples and exercises.

Re: List is a monad

#138

Post by instig007 »

chriswarbo wrote: post #131
ww520 wrote: post #24

Earlier quoted context omitted.

Here is an analogy. List is a container whose elements can be any type. There are general operations applying to a list, e.g. map, reduce, filter, find, etc. Any data type (int, float, or bool) of list elements can use these same operations regardless. It’s similar for monad. If you can provide a unit constructor to turn an object value into a monad value and a “map” operation that unwraps a monad value, applies a fu…

> a “map” operation that unwraps a monad value, applies a function to it, and wraps the result It can be misleading to think of "unwrapping" a monadic value, since the monad interface does not support it. For example, there's no way to implement a function `List -> T` using monad operations; it requires something entirely separate (e.g. indexing into a List, in this case). What monads do provide is `join`, which turn…

> For example, there's no way to implement a function `List -> T` using monad operations; it requires something entirely separate (e.g. indexing into a List, in this case).

this is called catamorphism, that is folding. The opposite transformation is called anamorphism, that is generation from a seed value.

Re: List is a monad

#139

Post by instig007 »

jameshart wrote: post #136
instig007 wrote: post #135

Earlier quoted context omitted.

now write a single function that performs from x in xs select fn(x) and define a signature for it where `xs` and `fn` are the only input arguments, so that it accepts both `listB` and `taskB` without a compilation error.

Right, ‘some type that has a Select(Func ) method available’ is not a thing you can express in C# generic constraints. But I don’t need a function that does that, the language has syntax for it - I can just do that wherever I need it.

> Right, ‘some type that has a Select(Func) method available’

not just Select(Func), but a Select(Func) that preserves its original contextual instance of Select and doesn't leak into a different instance with Select.

> But I don’t need a function that does that

you don't need it yet ;)

Re: List is a monad

#140

Post by zmgsabst »

macrolocal wrote: post #99
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…

Yep, you need category theory to express something as trivial as the definition of a monad.

That’s what category theory does well: broad collections of trivialities in a unified definition.
Post reply on HN