Exotic List Monads
hackage.haskell.org
Exotic List Monads
1–10 of 27 posts
Re: Exotic List Monads
#2No comments, because no one understand these (At least, I don't).
Re: Exotic List Monads
#3No comments, because no one understand these (At least, I don't).
Haskellers are asleep, let's post impure functions!
function() {console.log(Math.random())}
Re: Exotic List Monads
#4No comments, because no one understand these (At least, I don't).
It seems like understanding the exotic monads themselves is not the point. To me, that page mostly shows that monad laws allow some weird Monad instances on the same data structure.
The only exotic monad which was intuitive to me was GlobalFailure, which interprets lists as "Maybe NonEmpty": An empty list signifies failure and aborts the whole computation, while non-empty lists behave as normal.
Re: Exotic List Monads
#5I don’t see how this has broad appeal, but at least the Mazewalk interpretation is cute.
Re: Exotic List Monads
#6Re: Exotic List Monads
#7Re: Exotic List Monads
#8> The usual list monad is only one of infinitely many ways to turn the List functor into a monad.
So simple, and yet this is a point that I think is rarely made clear enough in "monad explainers." For instance, they almost always talk about "the Maybe monad" -- but this is conflating two things: the Maybe data type, and the Monad instance defined on that type. Propagating "Nothing" is not inherent to the Maybe data type, it's just a convenient behavior to have.
Talking about "the List monad" is even more confusing for a newcomer. When they hear "the List monad implements a kind of nondeterminism," it sounds like nondeterminism is a property inherent to lists themselves -- but of course it is nothing of the sort. All Monad instances are, in a sense, arbitrary.
Re: Exotic List Monads
#9I don’t see how this has broad appeal, but at least the Mazewalk interpretation is cute.
I think it's just meant to be fun and/or illustrative of a point.
Re: Exotic List Monads
#10> The usual list monad is only one of infinitely many ways to turn the List functor into a monad. So simple, and yet this is a point that I think is rarely made clear enough in "monad explainers." For instance, they almost always talk about "the Maybe monad" -- but this is conflating two things: the Maybe data type , and the Monad instance defined on that type. Propagating "Nothing" is not inherent to the Maybe data…
Part of this has to do with the fact that it is not possible (without tricks) to have multiple different typeclass implementations for one type in Haskell (I believe Rust also has this restriction). This language restriction has the tendency to seep into people's way of thinking about monads (and other typeclasses). However, it is not fundamental that a typeclass (or other ad-hoc polymorphism) system has this restriction.
That being said, the language design problem of how to support multiple different typeclass implementations for one type is actually trickier than you'd think. For example, it's easy to fall into the diamond problem if you don't have instance canonicity. If you're interested in how this problem can be solved in practice, check out this lovely paper about Modular Implicits in OCaml [1]. The paper is quite accessible if you have some FP background.