Monads

[Jerzy Karczmarczuk]

Rijk-Jan van Haaften >>= Hannah Schroeter:


> > ... However, not using the Monadic do syntax results in
> > hardly-readible code.
> 
> I don't really think so. The operator precedences for >> and >>= are
> quite okay, especially combined to the precedence of lambda binding.

...
> main = do
>         putStr "Hello! What's your name?"

...

> Yes, I use do syntax where appropriate (e.g. also for usual parser
> monads), however, the operator syntax can be written quite readably
> too.

I would add that sometimes you may be interested in Monadic SEMANTICS
at a more profound level, trying to hide it completely at the surface.
Then, the <<do>> syntax is an abomination.

The examples are already in the Wadler's "Essence". Imagine the 
construction of a small interpreter, a virtual machine which not only
evaluates the expressions (belonging to a trivial Monad), but perform
some side effects, or provides for exceptions propagated through a
chain of Maybes. Then the idea is to

* base the machine on the appropriate Monad
* "lift" all standard operators so that an innocent user can write (f x)
  and never x >>= f (or even worse).

The <<do>> construct in such a context resembles the programming in 
assembler, and calling it more readable is hmmmm... not very convincing.

(My favourite example is the "time-machine" monad, a counter-clock-wise
State Monad proposed once by Wadler, and used by myself to implement the
reverse automatic differentiation algorithm. Understanding what's going
on is difficult. The <<do>> syntax makes it *worse*.)

Jerzy Karczmarczuk
Caen, France