Live data from Hacker News

List is a monad

alexyorke.github.io

81–90 of 187 posts

Re: List is a monad

#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 more to the point.

The fact that explanations are so often in Haskell just makes them more unintelligible because you really need to know what problem they solve.

Re: List is a monad

#82
post #54
post #3

U must prove it is a monoid in the category of endofuncors.

> monoid in the category of endofuncors. I do not even know what a monoid or an endofuncor is. While I enjoy math, despite not being the best at it, I am confident I never made it this far in my studies. I looked at the Wikipedia definitions, and I am even more confused now.

https://bartoszmilewski.com/2016/12/27/monads-categorically/

This is a book chapter, and you need the preceding chapters to grasp it I think. I'm still in the middle of it.

Re: List is a monad

#83
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…

Thanks for the feedback! I'll likely be editing part 1 to include the feedback so far from the commenters as well. If there's a specific statement or analogy that felt especially confusing, please point it out and I'll clarify it in the post.

Re: List is a monad

#84
post #69

Earlier quoted context omitted.

This is not historically how Haskell was developed. Haskell didn't try to "avoid mutable state". Haskell tried to be (and indeed succeeded in being) referentially transparent. Now, it turns out that you can't uphold referential transparency whilst having access to mutable state in the "traditional" way, but you can access mutable state if you introduce monads as a means of structuring your computation. So, they're ce…

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 style. It turns out that both approaches could have been given monad interfaces if "monad" as an abstraction had been understood at the time, but it wasn't, so they had ad hoc interfaces instead.

> 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...

I mean, sort of, but that seems more of a judgement than a fact. Would you say that function calls in C were a way to "get around the limitations imposed by not allowing global jumps"?

In both cases I'd just say they're a useful abstraction that lets you achieve a well-specified goal whilst preserving some desirable language property.

Re: List is a monad

#85
post #83
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…

Thanks for the feedback! I'll likely be editing part 1 to include the feedback so far from the commenters as well. If there's a specific statement or analogy that felt especially confusing, please point it out and I'll clarify it in the post.

Sorry for moaning - it's just the usual despair that I feel every time I read a new explanation and fail to understand it. This isn't your fault.

Re: List is a monad

#86

The way I think of it, monads are a solution to Callback Hell, where you've fallen in love with lambdas, but now you have a nightmarish mess of lambdas in lambdas and lambdas calling lambdas. The monadic functions allow you to create "for comprehensions" aka "do comprehensions" but really, they look like a classic for-each loop. They secretly call the monadic map/flatMap/filter functions. for x in list doThings(x) Th…

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", "b"], ["c", "d"]] -> ["a", "b", "c", "d"]
This is usually expressed in a different form, more fundamental:

  M::flatMap(f: (T1 => M)): M
  List(["a b", "c d"]).flatMap(x => x.split()) == List(["a", "b", "c", "d"])
You can notice how that map() thing does looping over a sequence for you.

But Optional is also a monad:

  let x: Optional = Some(1);
  let y: Optional = Nothing;
  x.map(n => n + 1).map(n => n * 2) == Some(4);
  y.map(n => n + 1).map(n => n * 2) == Nothing;
As you see, the same map() (and flatMap()) does the condition checking for you. and can be chained safely.

You can also notice how chaining of map-like operations does operation sequencing:

  fetch(url).then(content => content.json()).then(data => process(data))
Your language, like JS/TS, can add some syntax sugar over it, and allow you to write it as a sequence of statements:

  async () => {
    const response = await fetch(url);
    const data = await response.json();
    process(data);
  } 
Promises are not exactly monads though, a Promise> immediately transforms into Promise. But other monadic properties are still there.

Re: List is a monad

#87
post #76

The amount of people who tie themselves into knots to understand this pointless concept is very funny to me. I am 16 years into a successful software engineering career without learning what a monad is an it never held me back. Turns out I can use lists and optional types and all that jazz without it. I mean really. Look at posts like this[0]. What does this give you? Nothing, in practical reality. Nothing. [0] https…

funny that you call it pointless then admit you never learned what it is

Re: List is a monad

#88
post #17

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...

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…

C# is a fun example because there is ongoing work to support Higher-Kinded Types in it: https://paullouth.com/higher-kinds-in-c-with-language-ext/

Re: List is a monad

#89
post #46
post #40

Earlier quoted context omitted.

The more constrained your theory is, the fewer models you have of it and also the more structure you can exploit. Monads, I think, offer enough structure in that we can exploit things like monad composition (as fraught as it is), monadic do/for syntax, and abstracting out "traversals" (over data structures most concretely, but also other sorts of traversals) with monadic accumulators. There's at least one other pract…

> There's at least one other practical advantage as well, that of "chunking". > When we have a grasp of relevant, powerful structures underlying our world, we can "chunk" along them to reason more quickly. This is one thing I've observed about Haskell vs. other languages: it more readily gives names and abstractions to even the minutest and most trivial patterns in software, so that seemingly novel problems can be qu…

Note that this is general enough that you don't need a Monad for this. Applicative is enough (liftA2).

Re: List is a monad

#90
post #51

Earlier quoted context omitted.

Nope. It's that there's only one lawful Functor instance. But Applicatives and Monads can be multiple - lists are the classic example (zip vs cross-product)

The cross-product is not to be confused with the Cartesian product, which is related to the (in this case unfortunately named) "cross join" in SQL. Cross products operate in ℝ³, while Cartesian products are just defined over sets. The standard List monad instance uses the latter.

ah yes my bad! good callout
Post reply on HN