On Fri, Sep 17, 2021 at 05:02:09PM +0000, Richard Eisenberg wrote:

...

On Sep 17, 2021, at 3:50 AM, Tom Ellis wrote:

On Fri, Sep 17, 2021 at 01:43:01PM +0900, Michael Turner wrote:

...

I finally got (most of?) what monads really mean for practical programming when none other than Simon Peyton-Jones said F# called a very similar construct "workflow," a word he likes.

Was it literally just a single sentence introducing a new word for a concept that made you "get it"? Could you elaborate? This is really quite remarkable.

For me, coming from a mostly Java background (but with a healthy dollop of functional programming thrown in the mix -- but no Haskell), the phrase that unlocked monads was "programmable semicolon".

I'm curious what "unlock" means here. Do you mean you could understand the definition of the monad class after coming across "programmable semicolon" but not before? Or do you mean you understood the *purpose* of monads, but not necessarily how one would go about implementing them? Or something else?

On Sep 17, 2021, at 1:11 PM, Tom Ellis wrote:

On Fri, Sep 17, 2021 at 05:02:09PM +0000, Richard Eisenberg wrote:

...

For me, coming from a mostly Java background (but with a healthy dollop of functional programming thrown in the mix -- but no Haskell), the phrase that unlocked monads was "programmable semicolon".

I'm curious what "unlock" means here.

It's hard to be sure, as this was ~10 years ago, but I think it was about motivation for me. Specifically: why do we need more than one monad, IO. I understood that Haskell functions were pure, and thus could produce no side effects. So we needed to have *some* way of having a program interact with the world. This way was the set of functions that work in the IO monad. These operations need a way of interacting with pure code (i.e. `return`) and some way of sequencing (i.e. >>=). This was all clear enough. What I didn't understand is why there was a typeclass to capture this or why we needed other monads -- until I associated "monad" with "programmable semicolon". At that point, I realized that the idea is very powerful. Richard

Do you mean you could understand the definition of the monad class after coming across "programmable semicolon" but not before? Or do you mean you understood the *purpose* of monads, but not necessarily how one would go about implementing them? Or something else? _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

On Fri, Sep 17, 2021 at 05:02:09PM +0000, Richard Eisenberg wrote:

...

Was it literally just a single sentence introducing a new word for a concept that made you "get it"? Could you elaborate? This is really quite remarkable.

For me, coming from a mostly Java background (but with a healthy dollop of functional programming thrown in the mix -- but no Haskell), the phrase that unlocked monads was "programmable semicolon".

No single exposition is optimal for all learners. Some are visual-spacial, others verbal-sequential, and there are likely other learning styles I've not heard of. Therefore, even with good writing, some readers will have to work harder at understanding the material than others, because they have to translate the explanations into a form that works for them. Also some readers are learning programming and Haskell at the same time, while others are experienced programmers, but not in Haskell or another ML-family or functional language. A reader far removed from the target audience of the writer may find a well written document largely unhelpful. There's no silver bullet. I haven't yet run into a "Haskell the language" book for experienced programmers that cuts to the chase and covers Haskell concisely a la K&R, focusing much more on the language than on how to write code (only as much code as it takes to minimally illustrate a language feature). Such a book would be challenging, because beyond writing basic numeric expresssions a large part of the language is needed all at once before one can write even some fairly simple functions. An off the cuff list of topics likely poorly ordered: * Basic expressions - Int, Word, Integer, Natural and Double - Infix operators, associativity and precedence, parentheses - Sections, (+), (.) and ($) - let and where - layout * Program structure - Function signature, head and body - patterns and pattern bindings - "case" and "if/then/else" - guards and pattern guards - modules, imports, and exports * User defined types - Algebraic data types, sums, products + Tuples + List (mention Array and Vector) + String (and mention Text) + Maybe + Either - Newtypes - Type aliases - GADTs - Existential types * More standard types - Array (immutable) - Vector (immutable) * Lazy evaluation and strictness - Space efficiency, seq and BangPatterns - ByteString strict, lazy and builders - Text strict, lazy and builders - Strict fields and StrictData * Type classes and constraints - Integral - Monoid - Semigroup - Foldable + Strict and lazy folds * Functors, Monads and Applicatives - State and IO Monads - map, fmap and ap - File I/O - Streaming - Applicative option parsing? * IO, ST and mutable values - MVector - MArray ... lots more ... before long we have a book that's considerably larger than K&R. This then leads to some frustration for the experienced programmer impatient to learn the basics of the language and get productive right away without relearning too much from the ground up. But then perhaps even modern C++ or Java has a rather non-trivial learning curve if one is starting from K&R C. There may not be a book that reasonably efficiently brings an experienced non-Haskell programmer to minimal proficiency, and the separation of pure functions from I/O means having to learn abstractions that don't come up in most other languages. For me, the journey was worth it, and the right book would surely have helped, (and would still help, I am far from the summit) but in the end it still takes effort and time. -- Viktor. P.S. Re: mental models of monads: Personally [verbal sequential], I find strained analogies unhelpful and distracting, so no desk clerks shuffling forms for me. I internalised Haskell monads, by implementing the Functor, Applicative and Monad instances for Reader and State a few times from scratch. Once those were solid, ReaderT and StateT and their MonadTrans instances. Unsurpsingly, I have a mental model built around sequencing of internal state updates while passing data from one state to use in choosing the next state transition. I do appreciate "programmable semicolon", but only *after* getting a more concrete intituition for the standard examples.

On Fri, Sep 17, 2021 at 09:14:23PM +0100, Tom Ellis wrote:

On Fri, Sep 17, 2021 at 03:47:19PM -0400, Viktor Dukhovni wrote:

...

I haven't yet run into a "Haskell the language" book for experienced programmers that cuts to the chase and covers Haskell concisely a la K&R, focusing much more on the language than on how to write code (only as much code as it takes to minimally illustrate a language feature).

The Haskell Report is a good start.

I agree that the report is a useful reference, but it is a specification, not a book from which to learn the language. I wouldn't actually suggest that anyone learn C by reading the C11 specication, or Haskell by working their way through the report. The report would of course be a useful source of topics and material for a Haskell the language book. -- Viktor.

On Fri, Sep 17, 2021 at 04:39:15PM -0400, Viktor Dukhovni wrote:

On Fri, Sep 17, 2021 at 09:14:23PM +0100, Tom Ellis wrote:

...

On Fri, Sep 17, 2021 at 03:47:19PM -0400, Viktor Dukhovni wrote:

...

I haven't yet run into a "Haskell the language" book for experienced programmers that cuts to the chase and covers Haskell concisely a la K&R, focusing much more on the language than on how to write code (only as much code as it takes to minimally illustrate a language feature).

The Haskell Report is a good start.

I agree that the report is a useful reference, but it is a specification, not a book from which to learn the language. I wouldn't actually suggest that anyone learn C by reading the C11 specication, or Haskell by working their way through the report.

My memory of K&R may be deceiving me, but I seem to recall it is a lot closer to the Haskell Report than the C11 standard is. I would be interested in the opinion of others who have read these documents more recently.

Seconded. This worked for me also as a good starting point. The report is quite readable. On 2021-09-18 12:15 +0300, Bryan Richter wrote:

I started learning Haskell by reading the Report, and I warmly recommend that strategy. In particular, I just skipped over the terminology that didn't make sense to me yet, and I didn't try too hard to keep the big picture in my head (suggestion to future versions: put all the BNF diagrams in the same place!)

Even with a rudimentary read-through, I was already advanced beyond the likes of LYAH and ready to start running simple programs in ghci. Even today I sometimes know things about syntax that surprise my colleagues.

I didn't need to know monads yet. The build tool challenges were a bigger stumbling block at that point.

But best of all, I was familiar with the reference material, so I could easily go back and reread things when necessary!

On Fri, 17 Sep 2021, 23.40 Viktor Dukhovni, wrote:

On Fri, Sep 17, 2021 at 09:14:23PM +0100, Tom Ellis wrote: > On Fri, Sep 17, 2021 at 03:47:19PM -0400, Viktor Dukhovni wrote: > > I haven't yet run into a "Haskell the language" book for experienced > > programmers that cuts to the chase and covers Haskell concisely a la > > K&R, focusing much more on the language than on how to write code (only > > as much code as it takes to minimally illustrate a language feature). > > The Haskell Report is a good start.

I agree that the report is a useful reference, but it is a specification, not a book from which to learn the language.  I wouldn't actually suggest that anyone learn C by reading the C11 specication, or Haskell by working their way through the report.

The report would of course be a useful source of topics and material for a Haskell the language book.

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

I suspect a lot of people were pleased that they'd finally gotten rid of lazy Result -> Request. On Fri, Sep 17, 2021 at 4:34 PM Joachim Durchholz wrote:

Am 17.09.21 um 21:47 schrieb Viktor Dukhovni:

...

Personally [verbal sequential], I find strained analogies unhelpful and distracting, so no desk clerks shuffling forms for me.

I internalised Haskell monads, by implementing the Functor, Applicative and Monad instances for Reader and State a few times from scratch. Once those were solid, ReaderT and StateT and their MonadTrans instances.

Unsurpsingly, I have a mental model built around sequencing of internal state updates while passing data from one state to use in choosing the next state transition.

I have been finding the Monad expositions misleading - that idea that monads are for sequencing or transitions or mutable state always felt wrong to me, since the monad laws don't talk about any of these things at all.

And as far as I could understand the concept, monads are not about state, they're about "composing a linear sequence of functions". The functions' types need not be the same (that would degenerate into the concept of associativity), but the result type of one function must be the parameter type of the next. The monad can do whatever it likes with the functions - typically, wrap them in some other function and construct a function composition; there isn't much else you can do with them, though you're not doing much justice to the Maybe monad if you see it as a pipeline. Ah... right... and of course the pseudo associativity. I.e. it doesn't matter what parts of the total sequence you construct first.

Of course, state transitions are a fine application of this concept. Or anything else where you see a function as a computation step and you want to run these steps in sequence. It's just that there are more kinds of monads. Except if you see Maybe as "do these operations in sequence until you hit the first that returns None, then abort". It depends on seeing functions as executable things though, and that's not really what Haskell is trying to be (or was trying to be 20 years ago, maybe everybody is now happy that Haskel finally can express imperative stuff via monads... no idea what people think)

Regards, Jo _______________________________________________ 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.

-- brandon s allbery kf8nh allbery.b@gmail.com

On Fri, Sep 17, 2021 at 3:52 PM Viktor Dukhovni wrote:

No single exposition is optimal for all learners. Some are visual-spacial, others verbal-sequential, and there are likely other learning styles I've not heard of.

If you'll forgive the slight argumentativeness, I do want to point out, as someone who follows education research quite a bit, that this learning styles hypothesis is a pretty well-known myth. It sounds good and feels true, but has been falsified every time someone has tried to gather evidence to validate it. There are some related statements that are true. For example, different people certainly have different preferences for modes of presentation, but those preferences don't actually correlate with how well they learn. Feeling confused or unsatisfied doesn't mean you're not learning! For another example, people definitely do learn better when they see information from several different points of view, but it's apparently not because different people learn best from different points of view, but rather because all people learn best when they have more different perspectives to integrate. And for a last example, people definitely do have preferences and abilities for learning different kinds of content, which are in turn most naturally communicated in certain ways, but it's apparently the natural way to present an idea that matters more in terms of learning, not the individual's preferences for style. This is actually pretty related to what we're talking about here. If it were true that different people understand monads better when they are presented in ways that match the individual's style of learning, reliable evidence of this would be revolutionary in education research. (Meaning: it's very, very likely not to be true, though I cannot point to research that studies understanding monads, in particular.) But luckily, the solution to this myth is just *not* to differentiate, but rather to provide all of these points of view to everyone who is learning, whether they *feel* that this is the right presentation or it *feels* like it's making sense to them or not. When evaluating our own learning experiences, we should be careful to remember that the times we were learning were probably actually the times we felt a bit confused. The presentation that finally made sense probably wasn't the most helpful one. See https://www.google.com/search?q=learning+styles+myth for lots of sources.