Wow Monads!

Wow Monads!

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:

I’m a pretty heavy Common Lisp guy, going on 30 years with it. I also did tons of SML and OCaml programming. But I only dipped my toe into Haskell a few times.

What I was looking for was a more in-depth understanding of Monads and how they work. I remember reading that Wadler paper many years ago, and I was intrigued by the conciseness of changing the interpreter to do different instrumentation. I was hoping to find a magic bullet like that for my Lisp code. And I noticed that Lisp almost never makes any mention of Monads. Surely there is a benefit that could be had…

Anyone else have Lisp experience using Monads? Did it offer some major enhancements for you?

Re: Wow Monads!

On Sat, 15 Apr 2017, David McClain wrote:

> 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>
> I’m a pretty heavy Common Lisp guy, going on 30 years with it. I also did tons of SML and OCaml programming. But I only dipped my toe into Haskell a few times.
>
> What I was looking for was a more in-depth understanding of Monads and how they work. I remember reading that Wadler paper many years ago, and I was intrigued by the conciseness
> of changing the interpreter to do different instrumentation. I was hoping to find a magic bullet like that for my Lisp code. And I noticed that Lisp almost never makes any
> mention of Monads. Surely there is a benefit that could be had…
>
> Anyone else have Lisp experience using Monads? Did it offer some major enhancements for you?
>
> - DM

Re: Wow Monads!

Using monads without static typing sounds hard. When I do anything monadic, I'm constantly using the :t directive to check type signatures, to make sure I'm plugging the right thing into the right thing.

I’m a pretty heavy Common Lisp guy, going on 30 years with it. I also did tons of SML and OCaml programming. But I only dipped my toe into Haskell a few times.

What I was looking for was a more in-depth understanding of Monads and how they work. I remember reading that Wadler paper many years ago, and I was intrigued by the conciseness
of changing the interpreter to do different instrumentation. I was hoping to find a magic bullet like that for my Lisp code. And I noticed that Lisp almost never makes any
mention of Monads. Surely there is a benefit that could be had…

Anyone else have Lisp experience using Monads? Did it offer some major enhancements for you?

Re: Wow Monads!

I don’t think it matters much about typing in this case. I am free to name the Monads anything I like, probably a name indicative of its purpose. I do see that if you insist on living by the conventional >> and >>= naming that it would need type checking to help it select the correct thing.

What’s more important is what a Monad does and enables. Everything else is window dressing.

Using monads without static typing sounds hard. When I do anything monadic, I'm constantly using the :t directive to check type signatures, to make sure I'm plugging the right thing into the right thing.

I’m a pretty heavy Common Lisp guy, going on 30 years with it. I also did tons of SML and OCaml programming. But I only dipped my toe into Haskell a few times.

What I was looking for was a more in-depth understanding of Monads and how they work. I remember reading that Wadler paper many years ago, and I was intrigued by the conciseness
of changing the interpreter to do different instrumentation. I was hoping to find a magic bullet like that for my Lisp code. And I noticed that Lisp almost never makes any
mention of Monads. Surely there is a benefit that could be had…

Anyone else have Lisp experience using Monads? Did it offer some major enhancements for you?

Re: Wow Monads!

MD> Anyone else have Lisp experience using Monads? Did it offer some major
MD> enhancements for you?

In Lisp, I don't think the abstraction buys you much, because all the
functionality you need (state, exceptions, runtime, etc) are always available
to all expressions. They become an excellent way of representing "extensible
composition" in a pure language that otherwise could not allow those things,
but I don't see that you need it for an untyped language like Lisp.

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-cafeOnly members subscribed via the mailman list are allowed to post.

Re: 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 <[hidden email]> 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.

Re: Wow Monads!

On 2017-04-16 03:13, John Wiegley wrote:
> MD> Anyone else have Lisp experience using Monads? Did it offer some major enhancements for you?
>
> In Lisp, I don't think the abstraction buys you much, because all the functionality you need (state, exceptions, runtime, etc) are always available to all expressions. They become an excellent way of representing "extensible composition" in a pure language that otherwise could not allow those things, but I don't see that you need it for an untyped language like Lisp.

May I present to you the lecture "Monads and Gonads" by Douglas
Crockford (https://www.youtube.com/watch?v=b0EF0VTs9Dc). He shows that
monads can make even a language like JavaScript useful (not his words).
And the talk is one of the better monad tutorials out there to boot, not
least because it's different from all the others.

My own conclusion from it is that I would maybe even turn your argument
around and claim that especially a language that has as few tools to
keep programs sensible as JS can benefit greatly from the structure a
monad provides. The benefits will be different for Lisp, but I imagine
there might be some nice use cases as well. After all, structures are a
great tool even if you're not forced to use them. ;)

On another note: the more I work with monads and their brethren, the
more I find myself thinking in terms of (a -> f b) functions instead of
things like bind. Not only is it closer to the mathematical basis, but
there's also the close relationship to lenses. I mention this because my
feeling is that this type of function is a more usable puzzle piece in
languages with limited syntax support. Especially if you also implement
functors. But that's just unsubstantiated gut feeling.

Re: Wow Monads!

That was absolutely excellent !! Great video presentation by Douglas Crockford. It took me about 2 hours to slowly advance through it, stopping along the way to translate his JS into Lisp to try out the Monads.

This is by far the clearest explanation of Monads that I have seen, from among at least 2 dozen different videos and blogs. Even clearer than that Wadler paper. I highly recommend viewing this presentation.

As for the rest of them, I hearken to the words of another great scientist who once stated that:

“If you can’t explain a problem to your grandmother so that she understands it, then you don’t really understand the problem yourself…"

- DM

>> On Apr 16, 2017, at 15:43, MarLinn <[hidden email]> wrote:
>>
>> On 2017-04-16 03:13, John Wiegley wrote:
>>> MD> Anyone else have Lisp experience using Monads? Did it offer some major enhancements for you?
>>>
>>> In Lisp, I don't think the abstraction buys you much, because all the functionality you need (state, exceptions, runtime, etc) are always available to all expressions. They become an excellent way of representing "extensible composition" in a pure language that otherwise could not allow those things, but I don't see that you need it for an untyped language like Lisp.
>>
>> May I present to you the lecture "Monads and Gonads" by Douglas Crockford (https://www.youtube.com/watch?v=b0EF0VTs9Dc). He shows that monads can make even a language like JavaScript useful (not his words). And the talk is one of the better monad tutorials out there to boot, not least because it's different from all the others.
>>
>> My own conclusion from it is that I would maybe even turn your argument around and claim that especially a language that has as few tools to keep programs sensible as JS can benefit greatly from the structure a monad provides. The benefits will be different for Lisp, but I imagine there might be some nice use cases as well. After all, structures are a great tool even if you're not forced to use them. ;)
>>
>> On another note: the more I work with monads and their brethren, the more I find myself thinking in terms of (a -> f b) functions instead of things like bind. Not only is it closer to the mathematical basis, but there's also the close relationship to lenses. I mention this because my feeling is that this type of function is a more usable puzzle piece in languages with limited syntax support. Especially if you also implement functors. But that's just unsubstantiated gut feeling.
>>
>> Cheers,
>> MarLinn
>>
>> _______________________________________________
>> 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.
>

Re: Wow Monads!

Am 16.04.2017 um 23:07 schrieb 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?!”

LOL okay :-D

I think they suffer from being awesome even if not well-understood, so
half-true statements about them get widely distributed.

What I still don't know is if their face value is overhyped or not.

The paper essentially displays how to do the visitor pattern in a
functional way. Nothing to see here, move on...
There are a few interesting aside points though:

One, that this kind of injection can be done in a type-safe way (not a
mean feat given the complexities of type parameters, but essentially
follows from the choice of type system and, interestingly, the absence
of side effects). This point is unrelated to monads, it's entirely
conceivable that some other structure could have been used instead.

Two, that the set of changes needed to turn a straightforward expression
tree into an injectable one is so small. It's a mixed blessing, because
the actual complexity of the definition is much larger than what you see
at a glance. However, it's unrelated to monads as well, it's a
consequence of having type inference and currying.

Three, that the injected structure does not need to be more than merely
conform to Monad, which is a pretty small core API (with "core" I mean
the set of functions that cannot be expressed as composition of other
API functions).
Now this is indeed related to monads, but to me, it's unclear how
important that finding is. I see monads being found all over the place,
but is that a consequence of the Monad structure being so simple and
permissive that it happens to match so many places in so many programs,
is it because there are useful monad libraries that people actively make
their code conform to the structure, is it perception bias (because
monads are well-discussed so people can identify a Monad in their code
but not an Arrow), or is Monad indeed tied to fundamental properties of
coding? Frankly, I don't even know how to test the hypotheses here.
What I do know is that we had a quite overhyped, simple but ubiquitous
data structure earlier: Lists. In the 80ies, there was that meme that
lists are the universal answers to data structures, mostly from the Lisp
camp where lists were indeed fundamental, ubiquitous, and so simple they
could be applied easily to all tasks. I haven't seen anybody seriously
entertaining that thought in years; it will be interesting to see
whether monads share that fate or prove to be something more fundamental.

Re: Wow Monads!

What I have been able to grok by translating into Lisp is that Monadic programming allows you to hide implicit accumulators, filters, control-flow (the Maybe Monad). Haskel absolutely needs Monads in order to force evaluation order in side-effecting places. Lisp doesn’t absolutely need Monads.

I won’t really know if programming in Monadic style actually makes better looking code or not - cleaner, easier to grok, performant, organized? - until I try to apply it in anger on a larger project. But I am happy now that I finally understand this often obfuscated beast. The monster is actually a tiny mouse.

I’m old enough now to have lived through at least two major programming fad cycles: Structured Programming followed by Object Oriented Programming. There are always nuggets to be found in any fad cycle, but unfortunately fad cycles always seem to swing to extremes. Psychologists would recognize that as borderline behavioral traits.

I totally ignored the Programming Patterns cycle, so whenever I hear references to such patterns I first have to Google them. I can appreciate that practitioners would want a taxonomy, but for myself, I see programming patterns in an entirely different light. I have been designing and programming computers for longer than most readers on this site have been alive. But programming has always been only a tool for me, a sharp pencil, a side channel, in the pursuit of physics.

Lisp has somehow managed to retain relevance to me throughout this entire period. I don’t choose languages for myself based on popularity. I want to get things done. And I want to do them quickly and move on to the next project.

So, being in Lisp, I am not overly concerned with type safety. I don’t have to live in a community of programmers all contributing to the project code base. I am in complete control of the projects in their entirety. But if this were not the case, then certainly a strong case can be made in favor of type strictness.

I did tons of SML and OCaml code about 10-15 years ago. I used to design languages and write commercial compilers for C and numerical analysis languages. But for my own uses, I find Lisp, on balance, to be my ultimate modeling clay.

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.

They might be useful to me.

- DM

> On Apr 17, 2017, at 01:58, Joachim Durchholz <[hidden email]> wrote:
>
> Am 16.04.2017 um 23:07 schrieb 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?!”
>
> LOL okay :-D
>
> I think they suffer from being awesome even if not well-understood, so half-true statements about them get widely distributed.
>
> What I still don't know is if their face value is overhyped or not.
>
> The paper essentially displays how to do the visitor pattern in a functional way. Nothing to see here, move on...
> There are a few interesting aside points though:
>
> One, that this kind of injection can be done in a type-safe way (not a mean feat given the complexities of type parameters, but essentially follows from the choice of type system and, interestingly, the absence of side effects). This point is unrelated to monads, it's entirely conceivable that some other structure could have been used instead.
>
> Two, that the set of changes needed to turn a straightforward expression tree into an injectable one is so small. It's a mixed blessing, because the actual complexity of the definition is much larger than what you see at a glance. However, it's unrelated to monads as well, it's a consequence of having type inference and currying.
>
> Three, that the injected structure does not need to be more than merely conform to Monad, which is a pretty small core API (with "core" I mean the set of functions that cannot be expressed as composition of other API functions).
> Now this is indeed related to monads, but to me, it's unclear how important that finding is. I see monads being found all over the place, but is that a consequence of the Monad structure being so simple and permissive that it happens to match so many places in so many programs, is it because there are useful monad libraries that people actively make their code conform to the structure, is it perception bias (because monads are well-discussed so people can identify a Monad in their code but not an Arrow), or is Monad indeed tied to fundamental properties of coding? Frankly, I don't even know how to test the hypotheses here.
> What I do know is that we had a quite overhyped, simple but ubiquitous data structure earlier: Lists. In the 80ies, there was that meme that lists are the universal answers to data structures, mostly from the Lisp camp where lists were indeed fundamental, ubiquitous, and so simple they could be applied easily to all tasks. I haven't seen anybody seriously entertaining that thought in years; it will be interesting to see whether monads share that fate or prove to be something more fundamental.
>
> Just my 2 cents :-)
> _______________________________________________
> 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.

Re: Wow Monads!

Am 17.04.2017 um 16:56 schrieb David McClain:
> I totally ignored the Programming Patterns cycle, so whenever I hear
> references to such patterns I first have to Google them. I can
> appreciate that practitioners would want a taxonomy, but for myself,
> I see programming patterns in an entirely different light. I have
> been designing and programming computers for longer than most readers
> on this site have been alive. But programming has always been only a
> tool for me, a sharp pencil, a side channel, in the pursuit of
> physics.

Programming is complicated enough to require its own terminology, so
it's more than a mere sharp pencil.

Design Patterns were a fad, but a pretty atypical one, because the
seminal work (the famous "Gang-of-Four Book") made it pretty clear what
a Design Pattern was good for and what it wouldn't do.
So a lot of the hyperbole was cut short.

Re: Wow Monads!

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.

Re: Wow Monads!

> 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 <[hidden email]> 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.

Re: Wow Monads!

Am 17.04.2017 um 21:26 schrieb David McClain:
> 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.

That's not the first time I hear such statements.
One other instance is Erlang users writing that it's not the functional
aspect that is making it effective (Erlang isn't particularly strong in
that area anyway), it's garbage collection (i.e. no invalid pointers to
dereference).

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

What happened with these OCaml programs?
I do see quite a few deficits in OCamls practices, but I don't know how
relevant they are or if they are even related to your experience, so
that would be interesting to me.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafeOnly members subscribed via the mailman list are allowed to post.

Re: Wow Monads!

> What happened with these OCaml programs?
> I do see quite a few deficits in OCamls practices, but I don't know how relevant they are or if they are even related to your experience, so that would be interesting to me.

Hi Joachim,

Not sure what you are asking here? Do you mean, are they still extant? or do you want to know the failure mechanisms?

The biggest program of the lot still remains, although I have not used it in nearly 10 years. It was a compiler for a math analysis language called NML (Numerical Modeling Language, Not ML, …). It borrowed the syntax of OCaml, was coded in OCaml, but was a vectorized math language with dynamic binding. For me, at the time, the biggest gain was treating all arrays as toroidal, so that I could easily play with FFT’s in multiple dimensions, and reach things like the tail of the array with negative indices. That, and the automatic vectorizing of overloaded math operators.

That particular program began to fail as a result of the continual evolution of OCaml. It became a chore to constantly adapt to ever changing syntax patterns, on again / off again preprocessing of AST trees etc. But it did serve me well for about 5 years. About 20 KLOC of OCaml and 3 KLOC of supporting C glue code for access to BLAS, FFT’s, plotting graphics, etc.

That NML effort was launched shortly after my initial success in the nonlinear optimization that I mentioned. This was also a huge success for me, because I had tried repeatedly over the previous 5 years to construct an NML in C, then C++, and I always crapped out when the line count reached around 100 KLOC. Being able to produce a fully working system in 20 KLOC was a huge win.

The other programs compiled properly, and yet failed in execution, but my recall is fuzzy. One of them had the job of trying to watch automobile traffic through several cameras, day and night, and try to give consistent identity to the images seen through separate cameras, their motion patterns, and so forth. The cameras did not have overlapping fields of view. Not an easy problem, especially on rainy nights with street reflections from headlights. I don’t recall the exact failures, but things like data structure Maps started to fail with Address Faults. That should not ever happen, according to theory, but it really does.

On and off, I did have quite a bit of success with OCaml. But getting clients to accept OCaml in the code base, c.a. 2000-2005 was a major problem. They all had their in-house experts telling them that C++ and Java was the way to go… (I managed to avoid Java in my career).

Another major project was an Embedded Scheme compiler aimed at DSP’s c.a. 2008. That worked quite well for me, no failures to speak of. But I did learn during that effort that pattern matching has its limits. You often want to match subtrees and stubs, and just writing them out becomes an exercise in write-only code. A fallback effort done later in Lisp succeeded even better, but that’s probably because of the lower impedance mismatch between Lisp / Scheme, compared to OCaml / Scheme.

I never learned nor made use of the OOP in OCaml. Never seemed necessary. But then they started implementing syntax sugar to represent optional args, etc. and quite frankly the effort looks really cheesy and difficult to read. You might as well just use Common Lisp and be done with it.

Then around 2008 I got invited to speak at the European Common Lisp Meeting in Hamburg, and they made their preferences for Lisp be strongly known. Despite whatever I had in OCaml, that would be of no interest to them. So I began reentry into Lisp in a serious way, and I have been there since. Lisp for me had been on/off since about 1985. There were side diversions into Forth, C, Objective-C-like compilers, Smalltalk, and lots of DSP coding in bare-metal DSP Assembly. Transputers and Occam for a while. Massively parallel computing on a 4096 processor SIMD DAP Machine, 46 node MIMD machines based on DSP / Transputers for airborne LIDAR underwater mine detection systems. Lots of history…

- DM

> On Apr 17, 2017, at 23:56, Joachim Durchholz <[hidden email]> wrote:
>
> Am 17.04.2017 um 21:26 schrieb David McClain:
>> 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.
>
> That's not the first time I hear such statements.
> One other instance is Erlang users writing that it's not the functional
> aspect that is making it effective (Erlang isn't particularly strong in
> that area anyway), it's garbage collection (i.e. no invalid pointers to
> dereference).
>
>> 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.
>
> What happened with these OCaml programs?
> I do see quite a few deficits in OCamls practices, but I don't know how relevant they are or if they are even related to your experience, so that would be interesting to me.
> _______________________________________________
> 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.

Re: Wow Monads!

Well, as I stated, I think failures come in several categories:

1. Machine Fault failures on successfully compiled code. That’s the big nasty one. Provably correct code can’t fail, right? But it sometimes does. And I think you can trace that to the need to interface with the real world. The underlying OS isn’t written in OCaml. Neither are many of the C-libs on which OCaml depends.

In an ideal world, where everything in sight has gone through type checking, you might do better. But that will never be the case, even when the current FPL Fad reaches its zenith. About that time, new architectures will appear underneath you and new fad cycles will be in their infancy and chomping at the bits to become the next wave… Reality is a constantly moving target. We always gear up to fight the last war, not the unseen unkowns headed our way.

2. Experimental languages are constantly moving tools with ever changing syntax and semantics. It becomes a huge chore to keep your code base up to date, and sooner or later you will stop trying. I have been through that cycle so many times before. Not just in OCaml. There is also RSI/IDL, C++ compilers ever since 1985, even C compilers.

The one constant, believe it or not, has been my Common Lisp. I’m still running code today, as part of my system environment, that I wrote back in 1990 and have never touched since then. It just continues to work. I don’t have one other example in another language where I can state that.

3. Even if the underlying language were fixed, the OS never changing, all libraries fully debugged and cast in concrete, the language that you use will likely have soft edges somewhere. For Pattern-based languages with full type decorations (e.g., row-type fields), attempting to match composite patterns over several tree layers becomes an exercise in write-only coding.

The lack of a good macro facility in current FPL is hindering. Yes, you can do some of it functionally, but that implies a performance hit. Sometimes the FPL compilers will allow you to see the initial AST parse trees and you might be able to implement a macro facility / syntax bending at that point. But then some wise guy back at language HQ decides that the AST tool is not really needed by anyone, and then you get stung for having depended on it. The manual effort to recode what had been machine generated becomes too much to bear.

4. I will fault any language system for programming that doesn’t give you an ecosystem to live inside of, to allow for incremental extensions, test, recoding, etc. Edit / compile / debug cycles are awful. FPL allows you to generally minimize the debug cycle, by having you live longer at the edit / compile stage.

But see some of the more recent work of Alan Kay and is now defunct project. They had entire GUI systems programmed in meta-language that compiles on the fly using JIT upon JIT. They make the claim that compilers were tools from another era, which they are, and that we should not be dealing with such things today.

Heck, even the 1976 Forth system, crummy as it was, offered a live-in ecosystem for programming.

So, that’s my short take on problems to be found in nearly all languages. There is no single perfect language, only languages best suited to some piece of your problem space. For me, Lisp offers a full toolbox and allows me to decide its shape in the moment. It doesn’t treat me like an idiot, and it doesn’t hold me to rigid world views. Is is perfect? Not by a long shot. But I haven’t found anything better yet…

- DM

> On Apr 18, 2017, at 08:18, Joachim Durchholz <[hidden email]> wrote:
>
> Am 18.04.2017 um 16:57 schrieb David McClain:
>>
>> Not sure what you are asking here? Do you mean, are they still
>> extant? or do you want to know the failure mechanisms?
>
> What failed for you when you were using OCaml.
> _______________________________________________
> 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.

Re: Wow Monads!

… step back about 40 years, and realize that people then understood the frailty of real machines.

When I first interviewed with IBM back in 1982, before going with them on another project, one project group explained to me that they were working on error correction codes for large disk drive cache memories. Back in those days, the ceramic IC packages had trace amount of radioactive isotopes, and every once in a while an alpha particle would smash into a DRAM cell, splattering the charge away and dropping or setting bits.

Now on a small memory system (a few KB in those days) the probability was low. But IBM was working on an 8 MB backing cache memory to speed up the disk I/O, and the likelihood of an errant bit worked out to about 1 per hour. That would be unacceptable. So IBM, like nearly all other memory manufacturers at the time, built memory systems with ECC.

Fast forward to day, and we have cheap Chinese production machines. No memory ECC at all. And memory density is even higher than before. Oh yes, they ultimately found improved manufacturing processes so that the alpha particles aren’t anywhere near the problem today that they were in 1982. But higher bit density today, larger memories, solar flares, cosmic rays, and plenty of code bloat that depends on perfectly held memory…

Who knows why an FPL module gives a machine fault? But they sometimes really do.

- DM

> On Apr 18, 2017, at 08:39, David McClain <[hidden email]> wrote:
>
> Well, as I stated, I think failures come in several categories:
>
> 1. Machine Fault failures on successfully compiled code. That’s the big nasty one. Provably correct code can’t fail, right? But it sometimes does. And I think you can trace that to the need to interface with the real world. The underlying OS isn’t written in OCaml. Neither are many of the C-libs on which OCaml depends.
>
> In an ideal world, where everything in sight has gone through type checking, you might do better. But that will never be the case, even when the current FPL Fad reaches its zenith. About that time, new architectures will appear underneath you and new fad cycles will be in their infancy and chomping at the bits to become the next wave… Reality is a constantly moving target. We always gear up to fight the last war, not the unseen unkowns headed our way.
>
> 2. Experimental languages are constantly moving tools with ever changing syntax and semantics. It becomes a huge chore to keep your code base up to date, and sooner or later you will stop trying. I have been through that cycle so many times before. Not just in OCaml. There is also RSI/IDL, C++ compilers ever since 1985, even C compilers.
>
> The one constant, believe it or not, has been my Common Lisp. I’m still running code today, as part of my system environment, that I wrote back in 1990 and have never touched since then. It just continues to work. I don’t have one other example in another language where I can state that.
>
> 3. Even if the underlying language were fixed, the OS never changing, all libraries fully debugged and cast in concrete, the language that you use will likely have soft edges somewhere. For Pattern-based languages with full type decorations (e.g., row-type fields), attempting to match composite patterns over several tree layers becomes an exercise in write-only coding.
>
> The lack of a good macro facility in current FPL is hindering. Yes, you can do some of it functionally, but that implies a performance hit. Sometimes the FPL compilers will allow you to see the initial AST parse trees and you might be able to implement a macro facility / syntax bending at that point. But then some wise guy back at language HQ decides that the AST tool is not really needed by anyone, and then you get stung for having depended on it. The manual effort to recode what had been machine generated becomes too much to bear.
>
> 4. I will fault any language system for programming that doesn’t give you an ecosystem to live inside of, to allow for incremental extensions, test, recoding, etc. Edit / compile / debug cycles are awful. FPL allows you to generally minimize the debug cycle, by having you live longer at the edit / compile stage.
>
> But see some of the more recent work of Alan Kay and is now defunct project. They had entire GUI systems programmed in meta-language that compiles on the fly using JIT upon JIT. They make the claim that compilers were tools from another era, which they are, and that we should not be dealing with such things today.
>
> Heck, even the 1976 Forth system, crummy as it was, offered a live-in ecosystem for programming.
>
> So, that’s my short take on problems to be found in nearly all languages. There is no single perfect language, only languages best suited to some piece of your problem space. For me, Lisp offers a full toolbox and allows me to decide its shape in the moment. It doesn’t treat me like an idiot, and it doesn’t hold me to rigid world views. Is is perfect? Not by a long shot. But I haven’t found anything better yet…
>
> - DM
>
>> On Apr 18, 2017, at 08:18, Joachim Durchholz <[hidden email]> wrote:
>>
>> Am 18.04.2017 um 16:57 schrieb David McClain:
>>>
>>> Not sure what you are asking here? Do you mean, are they still
>>> extant? or do you want to know the failure mechanisms?
>>
>> What failed for you when you were using OCaml.
>> _______________________________________________
>> 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.
>
> _______________________________________________
> 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.