Re: [Haskell-cafe] Wow Monads!

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 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...

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.