3 ms·

Can you describe a monad without using the words "functor", "applicative," "endofunctor" or using Haskel syntax to describe it?

by spc476 5y ago

redbar0n 5y ago
Elm creator Evan Czaplicki can, in an elegant and pedagogical way that would feel familiar to at least developers coming from JS: https://youtu.be/oYk8CKH7OhE?t=1454 https://youtu.be/oYk8CKH7OhE?t=1454 from 24:14 until 29:39. Haskell/FP/Math purists would probably balk at the oversimplification. But introducing intimidating concepts by way of such oversimplification (without entirely missing the target) is precisely the point! Beginners just need a very rough and coarse grained overview, so they are able to gain some basic familiarity with the concept. That gives them some already-familiar conceptual knobs to hang further details on, reduces fear, and inspires curiosity to investigate further.
dirkt 5y ago
"Overloaded semicolon with in-built assignment of the value of the first statement".
juxtapose 5y ago
It's not hard to describe what monads are, but it's probably not going to convince anyone of its importance without an appropriate language. The monad per se is an extremely simple idea. In fact, monadic interfaces are ubiquitous: Rust: Result::and_then() Scala: Option.flatMap() JS: Promise.then() ... I agree it can take some time to discover the similarities between these interfaces. But a monad is just that. It's so simple that we are blind to see. Unfortunately, it requires a sufficiently advanced language to express the concept of Monad. You need at least higher-kinded types and means to describe behaviors of HKTs. Can you understand or describe monads in a less powerful language, say Rust? Definitely! But will you appreciate the power that monads give you in Rust? Probably no.
duped 5y ago
Sure, here's the practical description : A monad is a data structure that holds one value, but that value may be of one of several types. It implements a `map` function which allows conversion to the same monad with different set of types, eg there is some function `map` defined as : fn map ( f : Tn -> Un, Monad<T1, T2, ..., Tn, ... TN>) -> Monad<T1, T2, ..., Um, ..., TN) for each type the value may be in the Monad. Two commonly used examples are the Optional and Result monads. An Optional is either a value of type T, or the empty type None. A Result is a value of type T or some error E. The utility of monads is their ability to chain operations. With optionals, you can map the results of functions that may or may not return results without handling the None case explicitly. With Result types you may chain operations that return errors, and handle both the successes and cases where you need to convert errors. Monads can be expressed in many languages, but they make the most sense in languages with algebraic data types (to express a value is one of a set of possible types, aka union/sum types) and first-class functions (where functions can be passed as an argument, or else implementing `map` may be difficult). The mathematical parlance is really harmful to their adoption because as an abstraction, monads are stupidly easy to use.
- kaba0 5y ago
  I think you describe only a Functor, not a Monad. A Monad also has to have either a `bind` or a `flatmap` function, besides the `(f)map`. Basically the point of a monad is to depend on the output of another monad data type of its kind — e.g. it can take an IO String and use the encapsulated String value to produce another IO X. This would be IO (IO X) without the flatmap, or the bind function that can remove this double encapsulation.
  - duped 5y ago
    This is what I was attempting to describe. `bind` is implicit, it's the constructor of a monad. In my definition `map` is serving the purpose of your flatmap, I didn't mean to imply double encapsulation.
chriswarbo 5y ago
Wrappable, Mappable and Collapsable (i.e. return/pure, map and join)
kryptiskt 5y ago
A monad isn't a concrete thing, a monad is a pattern that lots of different types adhere to. So it makes sense to extract it into an interface, in that operations that only use the monadicness can be implemented once for all types that are monads. It doesn't make much sense to study monads apart from the things that implement the interface, because there is not much to it. It's just an interface for the abstract notion of an ordered sequence of actions.

Can you describe a monad without using the words "functor", "applicative," "endofunctor" or using Haskel syntax to describe it?

by spc476 5y ago

Can you describe a monad without using the words "functor", "applicative," "endofunctor" or using Haskel syntax to describe it?

redbar0n 5y ago

Elm creator Evan Czaplicki can, in an elegant and pedagogical way that would feel familiar to at least developers coming from JS: https://youtu.be/oYk8CKH7OhE?t=1454 https://youtu.be/oYk8CKH7OhE?t=1454 from 24:14 until 29:39. Haskell/FP/Math purists would probably balk at the oversimplification. But introducing intimidating concepts by way of such oversimplification (without entirely missing the target) is precisely the point! Beginners just need a very rough and coarse grained overview, so they are able to gain some basic familiarity with the concept. That gives them some already-familiar conceptual knobs to hang further details on, reduces fear, and inspires curiosity to investigate further.

dirkt 5y ago

"Overloaded semicolon with in-built assignment of the value of the first statement".

juxtapose 5y ago

It's not hard to describe what monads are, but it's probably not going to convince anyone of its importance without an appropriate language. The monad per se is an extremely simple idea. In fact, monadic interfaces are ubiquitous: Rust: Result::and_then() Scala: Option.flatMap() JS: Promise.then() ... I agree it can take some time to discover the similarities between these interfaces. But a monad is just that. It's so simple that we are blind to see. Unfortunately, it requires a sufficiently advanced language to express the concept of Monad. You need at least higher-kinded types and means to describe behaviors of HKTs. Can you understand or describe monads in a less powerful language, say Rust? Definitely! But will you appreciate the power that monads give you in Rust? Probably no.

duped 5y ago

Sure, here's the practical description : A monad is a data structure that holds one value, but that value may be of one of several types. It implements a `map` function which allows conversion to the same monad with different set of types, eg there is some function `map` defined as : fn map ( f : Tn -> Un, Monad<T1, T2, ..., Tn, ... TN>) -> Monad<T1, T2, ..., Um, ..., TN) for each type the value may be in the Monad. Two commonly used examples are the Optional and Result monads. An Optional is either a value of type T, or the empty type None. A Result is a value of type T or some error E. The utility of monads is their ability to chain operations. With optionals, you can map the results of functions that may or may not return results without handling the None case explicitly. With Result types you may chain operations that return errors, and handle both the successes and cases where you need to convert errors. Monads can be expressed in many languages, but they make the most sense in languages with algebraic data types (to express a value is one of a set of possible types, aka union/sum types) and first-class functions (where functions can be passed as an argument, or else implementing `map` may be difficult). The mathematical parlance is really harmful to their adoption because as an abstraction, monads are stupidly easy to use.

kaba0 5y ago
I think you describe only a Functor, not a Monad. A Monad also has to have either a `bind` or a `flatmap` function, besides the `(f)map`. Basically the point of a monad is to depend on the output of another monad data type of its kind — e.g. it can take an IO String and use the encapsulated String value to produce another IO X. This would be IO (IO X) without the flatmap, or the bind function that can remove this double encapsulation.
- duped 5y ago
  This is what I was attempting to describe. `bind` is implicit, it's the constructor of a monad. In my definition `map` is serving the purpose of your flatmap, I didn't mean to imply double encapsulation.

chriswarbo 5y ago

Wrappable, Mappable and Collapsable (i.e. return/pure, map and join)

kryptiskt 5y ago

A monad isn't a concrete thing, a monad is a pattern that lots of different types adhere to. So it makes sense to extract it into an interface, in that operations that only use the monadicness can be implemented once for all types that are monads. It doesn't make much sense to study monads apart from the things that implement the interface, because there is not much to it. It's just an interface for the abstract notion of an ordered sequence of actions.