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

181–187 of 187 posts

Re: List is a monad

#181

Post by StopDisinfo910 »

pdhborges wrote: post #12
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…

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

The truth is that it’s not a very useful abstraction in and of itself.

You can build some generic tooling on top of monads and applicatives and that tooling is useful and can give familiarity to new data structures but objectively that’s true mostly because monads are so common in Haskell. Thinking monads are common for this reason is reversing cause and consequence.

So why are monads so prevalent in Haskell, you will ask. Because there is sugar to make their use easy. And why is there sugar? Because I/O uses a monadic interface. That was Haskell new idea. You can easily keep track of side effects with the type system if you use a monadic interface and some sugar.

Re: List is a monad

#182

Post by psyleft »

I still think the best way to conceptualize a monad is a "wrapper" around some data that contains additional state. The critical part of this definition is the second half, which sometimes gets skipped over for simplicity but is really what ties together all the disparate uses of monads.

The most convincing description of this idea imo is this video by Tsoding: https://www.youtube.com/watch?v=fCoQb-zqYDI

Re: List is a monad

#183

Post by chongli »

cynicalkane wrote: post #172
chongli wrote: post #146

Earlier quoted context omitted.

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 othe…

Very misleading since monoids include a binary operator and the algebraic definition of commutative would imply that A * B = B * A. Clearly this is false if A and B are strings and * is concatenation (which forms a monoid with the empty string as identity).

Re: List is a monad

#184

Post by ww520 »

maleldil wrote: post #91
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…

You're describing a functor. For monads, you still need bind or join.

It's not a functor; "map" is bind. Here's an example in non-Haskell as I was addressing non-Haskell audience.

  class Maybe {
    value: int;

    static wrap(v: int) { 
        return new Maybe { value = v } 
    }

    // map() applies fn on the unwrapped value. fn returns a Maybe. 
    map(fn: (x: int) => Maybe) {
        return this.value == null ? Maybe.wrap(null) : fn(this.value);
    }
  }
Here Maybe.wrap() is "unit" and Maybe.map() is "bind" in Haskell lingo. The whole thing is a monad. You can chain call with it.

  Maybe.wrap(5)
       .map(x => Maybe.wrap(x + 1))
       .map(x => Maybe.wrap(x * 2))

Re: List is a monad

#185

Post by danieltanfh95 »

petesergeant wrote: post #132
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.

a standard api is the magic. when you can talk to anything via a standard api it creates uniformity and standard blocks you can build from

Re: List is a monad

#186

Post by danieltanfh95 »

lmm wrote: post #123
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…

Associativity is important, and not something that can be expressed in the API in most languages.

Associativity is part of the contract/specifications of said "standard API"

Re: List is a monad

#187

Post by maleldil »

ww520 wrote: post #184
maleldil wrote: post #91

Earlier quoted context omitted.

You're describing a functor. For monads, you still need bind or join.

It's not a functor; "map" is bind. Here's an example in non-Haskell as I was addressing non-Haskell audience. class Maybe { value: int; static wrap(v: int) { return new Maybe { value = v } } // map() applies fn on the unwrapped value. fn returns a Maybe. map(fn: (x: int) => Maybe) { return this.value == null ? Maybe.wrap(null) : fn(this.value); } } Here Maybe.wrap() is "unit" and Maybe.map() is "bind" in Haskell ling…

Haskell bind is usually spelt flatMap in other languages, like Rust and even Java. map is used for functor fmap.
Post reply on HN