Monads Are Too Powerful: the Expressiveness Spectrum

I maintain that the big advantage of the On Lisp approach is that all of that is available without having to write a new compiler.

Granted, I also don't have as heavy an attachment to pure functional as most people seem to build. Don't get me wrong, wanton nonsense is nonsensical. But that is just as true in immutable contexts.

> if you can write compilers anything that involves composing functions is weak beer

> screwing around with functions and macros doesn't hold a candle to what you learn from the Dragon Book.

---

So, what is it that you learn from that book that's a revelation for you compared to the weak beer of composable effect systems?

> screwing around with functions and macros doesn't hold a candle to what you learn from the Dragon Book

This depends a lot on what you mean. My first take is that the more you know about macros the more you realize what they can do.

I don’t know what your takeaway from the Dragon Book was, but writing DSLs using macros feels very usefully powerful to me.

I think you are undervaluing modern macros.

But lisp programs are compilers. That's the whole point of lisp and macros. Your functions can happily emit assembly direction.

I don't think you're being fair to Chris Penner. He ends his blog post with: "It may take me another 5 years to finally finish it, but at some point we'll continue this journey and explore how we can sequence effects using the hierarchy of Category classes instead." Emphasis by me.

So while it is true, that what he has described so far is not sufficiently powerful for normal programs, he has clearly stated that there are more abstractions between Applicative and Monad to explore than what he has presented so far.

I'd say the family resemblance is the other way around. F# was influenced by Haskell, both in syntax and semantics. Just as Haskell was influenced by early ML.

Haskell and ML make up one of the major language families. They are more like each other than they are like other languages. Inspired by the lambda calculus. Strong static typing with type inference. A succinct math-like syntax that emphasizes pattern matching.

Haskell goes further with syntactic sugar and tries to be almost equation-like:

    a = 5
    f = \x -> x + 1
    g x = x + 2
    f $ g a

SML:

    val a = 5
    val f = fn x => x + 1
    fun g x = x + 2
    f (g a)

But F# like Haskell makes no distinction between values and functions:

    let a = 5
    let f = fun x -> x + 1
    let g x = x + 2
    f (g a)

The use of indent-based blocks is another Haskell-ish influence on F#. But now we're awfully close to bikeshedding.

Paging John Harrop...

https://news.ycombinator.com/item?id=1396763

The important thing to know first is that a monad is not a single thing like "Optional". "monad" is a pattern or "interface" (called a "typeclass" in Haskell), that has many implementations, (Optional, Either, List, State Transormer, IO (Input/Output), Logger, Continuation, etc). Sort of how "Visitor" pattern in C++/Java is not a single thing.

https://hackage.haskell.org/package/base-4.21.0.0/docs/Contr...

https://book.realworldhaskell.org/read/monads.html

A common metaphor for monad is "executable semicolons". They are effectively a way to add (structured) hook computations (that always returns a specific type of value) to run every time a "main" computation (akin to a "statement" in other languages) occurs "in" the monad.

It's sort of like a decorator in Python, but more structured. It lets you write a series of simple computational steps (transforming values), and then "dress them up" / "clean them up" by adding a specific computation to run after each step.

    mapM :: (Traversable t, Monad m) => (a -> m b) -> t a -> m (t b)

Unfortunately no one can tell you what a monad is. You have to experience it for yourself. - Haskell Morpheus

You should first understand what a typeclass and a Functor is.

A monad is just a monoid in the category of endofunctors

Forget all the academic definitions, at it's core a monad is a container or wrapper that adds additional functionality to a type.

Someone may correct me but - in three levels of conciseness...

A monad is a function that can be combined with other functions.

It's a closure (or functor to the cool kids) that can be bound and arranged into a more complex composite closure without a specification of any actual value to operate on.

It's a lazy operation declaration that can operate over a class of types rather than a specific type (though a type is a class of types with just a single type so this is more a note on potential rather than necessary utility) that can be composed and manipulated in languages like Haskell to easily create large declarative blocks of code that are very easy to understand and lend themselves easily to abstract proofs about execution.

You've probably used them or a pattern like them in your code without realizing it.

Monads are a generalization of Promises. Each type in Monad defines their own `.then` in a different way. For promises, `.then` is defined as "run this function once you have this deferred value from the last promise". For optionals (`Maybe`), `.then` is defined as "run this function if the last optional had an actual value". For Either, `.then` is defined as "run this function if the last Either returned Right, otherwise early-return with the value from Left" (this is functional early-return, basically).

    λ> do { a <- [1,2]; pure a; }
    [1,2]
    -- oh so it returns the list unchanged
    λ> do { a <- [1,2]; b <- [3,4]; pure a; }
    [1,1,2,2]
    -- no what is this spooky action at a distance
    λ> do { a <- [1,2]; b <- [3,4]; pure [a]; }
    [[1],[1],[2],[2]]
    -- ...
    λ> do { a <- [1,2]; b <- [3,4]; c <- []; pure [a]; }
    []
    λ> do { a <- [1,2]; b <- [3,4]; c <- [5]; pure [a,b,c]; }
    [[1,3,5],[1,4,5],[2,3,5],[2,4,5]]

Nan-in received a university professor who came to inquire about Monads

Nan-in served tea. He poured his visitor’s cup full, and then kept on pouring.

The professor watched the overflow until he no longer could restrain himself. “It is overfull. No more will go in!”

“Like this cup,” Nan-in said, “you are full of your own opinions and speculations. How can I show you a Monad unless you first empty your cup?”

Monad is a pattern for constructing container types so that their instances can be used in chain operations safely. Given a value type, you can build a monad type wrapping the value type with a set of prescribed monadic functions. Instances of the monad type are called monadic values.

Example is best for illustration. I'll use a made-up syntax.

  // 'Maybe' is a monad wrapping any value type T that can be null.
  class Maybe<T> {
    // The value wrapped by the monadic value
    value: T;

    // A constructor to make a Maybe monadic value from a plain value T.
    // This is called 'unit' or 'return' in Haskell, or 'lift' in other languages.
    // It's really a constructor.
    static wrap(v: T) Maybe<T> {
        return new Maybe { value = v } 
    }

    // then() applies fn on the unwrapped value. fn returns a Maybe<T>.
    // This is called 'bind' in Haskell, or 'flatMap' in other languages.
    then(fn: (T) => Maybe<T>) Maybe<T> {
        return this.value == null ? Maybe.wrap(null) : fn(this.value);
    }
  }

That's it! That's all to to monad. You can use the same pattern to build other monadic types, like List<T>, Promise<T>, IO<T>, as long as the wrap() and then() functions are built accordingly. Back to this example, to use it,

  let a = Maybe<int>.wrap(4)                   // construct a monadic value
  let b = a.then(x => Maybe<int>.wrap(x + 1))  // add 1 to it
  let c = Maybe<int>.wrap(null)                // construct a null monadic value
  let d = c.then(x => Maybe<int>.wrap(x + 1))  // safely handle null; d is null

  let e = Maybe<int>.wrap(5)
    .then(x => Maybe<int>.wrap(x + 1))
    .then(x => Maybe<int>.wrap(x * 2))    // chain the calls

  let f = Maybe<float>.wrap(5.0)          // The same Maybe on a different type
    .then(x => Maybe<float>.wrap(null))
    .then(x => Maybe<float>.wrap(x * 2))  // chain the calls; safely handle null

Just think of it as a design pattern, but a bit more strict than the Gang of Four patterns. Fundamentally it's a relationship between types and other types such that certain operations make sense and follow well-understood rules (the monadic laws). Study the monadic laws, and try playing with the State, IO, and List monads to get a better sense of what those operations are and why they're useful for sequencing in a pure-functional context.

beats me. I spent so much time learning what a fundamental group is and I still cannot tell ppl what a fundamental group is convincingly.

I can’t even make stuff with fundamental groups.

It's an implementation of the typeclass Monad, which happens to come with a special "do" keyword.

This is great imo -- https://www.adit.io/posts/2013-04-17-functors,_applicatives,...

The largest problem I found when I was going through the same thing was that every explanation that's trying to provide a non-abstract answer will always suffer the flaw of not being universally true. Because they're an abstract concept.

If someone paired this with a code-lite GUI designer, the world would be a brighter place indeed