[Haskell-cafe] Wow Monads!

[Joachim Durchholz]

Am 15.04.2017 um 18:56 schrieb David McClain:
> It’s been about 15 years on/off since I first looked at Monads. This
> weekend I finally sat down and really learned what they are, how they
> work. I found what looks like the seminal paper on them by Phil Wadler:
>
> https://page.mi.fu-berlin.de/scravy/realworldhaskell/materialien/the-essence-of-functional-programming.pdf

What I think he's doing is:
- Define a standard language core.
- Instead of hardcoding function application, he defers that to a 
function passed in as an externally-supplied parameter.
- Various cleanup definition so that the construction properly 
interoperates with primitive values and primitive functions.
- Leave the type parameter for the externally-supplied function from the 
signatures, for Haskell's type inference to determine. So all the 
signatures look much simpler than they really are; one could call this 
either "excellent abstraction" or "muddling the water so nobody sees 
what's going on", depending on how well one can read this kind of idiom.

I didn't see this as "particularly wow"; I have seen similar things 
being done in Java EE (all those "request/response interceptor chains").

What would "wow" me was a language where this kind of technique were 
automatically present even if the author of the expression evaluator 
didn't prepare for it. I.e. if the language provided a way to take such 
an expression evaluator as in the paper, and gave people a way to add a 
monad in a post-hoc fashion (because expression evaluator designers 
typically forget to add this kind of feature, unless they have written a 
dozen of these things already).
This kind of thing is also relatively easy to do in Java or any other 
language with parametric polymorphism, though adding the function 
parameter all over the place would be a pain in the @ss. Yeah I know 
that Phil highlights this as a plus, "just add these three lines and 
everything is automatically parametrized" - having worked with 
sub-average programmers and having done a lot of legacy maintenance, I'd 
say it's a strong minus because a single definition at the innermost 
level will substantially change the signature of the whole thing, 
suddenly you have a monad parameter in all the types. (I'm not 100% sure 
whether this is such a big problem, because it seems that monads are 
about the only thing you need to worry about in practice - everybody is 
talking about monad transformers and such, I don't see arrows and all 
the other higher-order-typing constructions given much attention in 
practice).

(Full disclosure: Java programmer with interest in better ways to 
construct software, long-time Haskell lurker with several attempts at 
wrapping the mind around various concepts in life and found roughly 
one-third of them firmly in the "nice but grossly overhyped"... even 
after 20 years I'm still not decided about whether monads are in that 
category or not (pun unintended, honest!).)