[Haskell-cafe] Wow Monads!

[David McClain]

> who _does_ understand monads[1] and can remember that his presentation
> seemed *incredibly* fuzzy and imprecise.

Interesting comment… I was just reading up on the history of Pure Lisp, and the earliest attempts at reconciling mathematics with the early Lisp interpreters. In there they pointed out the initial disparity between denotational semantics and operational semantics.

What I gained from Crockford’s presentation was a (my own in Lisp) clean implementation of operators called Unit and Bind, and I find those to be quite operationally simple, clever, and potentially useful. However, I have not attempted the verification with the 3 Monadic Lemmas on my own. Two of them should be quite obvious by inspection. The third, relating to functional composition awaits scrutiny.

But beyond that, I find the general framework potentially useful. As I mentioned, they should be capable of accumulation (lists, binding trees, environments, etc), filtering out elements during accumulation, and control flow (the Maybe Monad). All of these are clear in my mind, and require only minor modifications to the specific implementations of the generic Bind operator.

Now, I am hugely experienced in not only Lisp, but going all the way back down to pre-C languages and Assembly. So I have a pretty solid understanding of operational semantics. I am not personally frightened, for my own projects, of typing issues. I would be more scared if I had to exist in a group of programmers, all of whom contribute to the project code base. My own projects only rarely suffer from type issues. A bigger category of mistakes comes from simple keyboard typos and incorrect choice of algorithms. Apart from choice of algorithms, I find typically 1 bug per 50-100 LOC (operational lines). Compared to C, that is a factor of 10’s less bug prone. Add to that, the increased semantic value of 1 LOC of Lisp compared to C, and you get an efficiency increase of 1,000’s. But even in C, the typing is not the main issue, at least it hasn’t been for me.

When I initially embarked on SML and OCaml, back in the late 1990’s, I was initially enthralled by the power of strong typing with inference. I was able to solve a nonlinear optimization over 150+ DOF  using OCaml, whereas we had been stuck and bombing out after only 5 DOF using the strictly imperative Fortran-like language we had been using. I was so impressed, that word got out, and Phil Wadler invited me to write up my findings for his ACM Letters, which I did.

And BTW… the breakthrough had absolutely nothing to do with typing and type inference. The success arose because of clean versus unclean control-flow. So you could say that OCaml adhered to “Structured Programming” in a better manner, which corresponds entirely to a fad cycle 2 layers back in time.

But then after several years of pushing forward with OCaml, in writing math analysis compilers and image recognition systems, I began to find that, despite proper typing and clean compiles, system level issues would arise and cause my programs to fail. The holy grail of provably correct code came tumbling down in the face of practical reality. 

That’s when I began migrating back over to my old standby Lisp system. I live inside of my Lisp all day long, for days on end. It is a whole ecosystem. There is not crisp boundary of edit / compile / debug. It is all incremental and extensional. I think that kind of environment, regardless of language, is the holy grail of computing. I even had that kind of experience back in the late 1970’s when we were writing large telescope control systems in Forth.

- DM

> On Apr 17, 2017, at 11:12, Bardur Arantsson <spam at scientician.net> wrote:
> 
> On 2017-04-17 16:56, David McClain wrote:
>> 
>> Monads were always a hole in my knowledge. I read Phil Wadler’s paper more than a decade ago, and I remember being impressed at the terseness of his little interpreter. But Monads kept being offered with all the extraneous Category Theory stuff, and all the black-box mysticism. Now that I have seen Crockford's video, translated his JavaScript into my Lisp, I thoroughly get what they are all about in languages like Javascript and now Lisp. 
>> 
> 
> Beware that Crockford's understanding of monads itself has been
> questioned (based on this talk). It's been ages since I saw his video
> and don't feel inclined to watch it again, but I fancy myself as someone
> who _does_ understand monads[1] and can remember that his presentation
> seemed *incredibly* fuzzy and imprecise.
> 
> This might give one the impression that they do understand, when they
> really don't.
> 
> I'm not saying that's the case here, but it's something that anyone
> watching his video should be aware of. The only way to be sure is to try
> to implement some monads and monad transformers for yourself.
> 
> (I'd be absolutely *terrified*, personally, of doing it in a unityped
> langauge because there are *so* many ways to get it subtly wrong and not
> know it until you hit exactly the "right" edge case. Heck, I even find
> it somewhat scary in Scala because it's rather easy to accidentally do
> something impure -- though if you're abstract about your types, you can
> usually avoid such accidents.)
> 
> Btw, from my perspecitve the thing that makes monads work for arbitrary
> side effects is really *data dependencies* + the fact that IO is a sort
> of "fake" State World monad where you pretend that you always fully
> evaluate the World argument to the "next step". For anything non-IO it's
> really just a way to do arbitrary *control flow* based on runtime values
> -- whereas e.g. Applicative doesn't let you do that[2]. A more direct
> approach would be Algebraic Effects.
> 
> Regards,
> 
> [1] At least at an "intermediate" level. If you just go by the type
> signatures and desugaring it doesn't seem all that complicated to me,
> but whatever. I've always been inclined towards algebra/symbol
> manipulation, so maybe it's just me.
> 
> [2] You can kind of simulate it, but you basically end up evaluating
> everything and "wasting computation" by redundant evaluation. You can
> think of it as always having to evaluate both branches of all if's and
> then choosing the result afterwards. Obviously, that doesn't work if you
> have *actual* side effects.
> 
> _______________________________________________
> 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.