[Haskell-cafe] Wow Monads!

[David McClain]

Heh!! My title “Wow” was not an expression of wonderment. Rather it was “Holy Cow! Monads, how can you guys be so obtuse?!”

- DM


> On Apr 16, 2017, at 03:00, Joachim Durchholz <jo at durchholz.org> wrote:
> 
> 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!).)
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.