Re: [Haskell-cafe] Better writing about Haskell through multi-metaphor learning

Am 20.09.21 um 19:50 schrieb Viktor Dukhovni:

...

On 20 Sep 2021, at 2:30 am, Joachim Durchholz wrote:

The idea is that a monad is a tool to construct a pipeline inside a Haskell program. I think. It isn't my metaphor either, I have seen various people in this thread mention it in passing.

A "pipeline" is not necessarily a *static* pipeline. Even in "bash" we have conditional branching:

Sure, but we're talking about imagery in the heads of people. And few see things like conditional pipelines.

So IO and State and Maybe and Either all fit.

In a sense, yes. But it requires an additional step - the pipeline itself is active and can be involved in decisionmaking. BTW I don't think that IO is really a pipeline. If you have inputs and decisionmaking, you have a decision tree. I believe the program takes just one path through that tree, but I don't understand IO well enough to validate that assumption.

As noted a few times in this thread List takes multiple paths. The "non-determinism" (something that not always explained well, since taking all paths is still rather deterministic) extends the simple pipeline model.

Yeah, actually it's fully deterministic, my wording was a bit too sloppy.

Where pipelines really don't appear to me to be an adequate mental model is "Cont". Reifying continuations feels very different from even a non-deterministic pipeline. Even "programmable semicolon" likely does not yield much intuition about "Cont".

But, to first approximation, and without suffering any harm thereby, pipelines have worked well for me (and I expect others). I know that's not the whole/real story, I don't need the model as a crutch, but it works well enough, often enough to remain a useful way of reasoning about the many situations in which it is applicable.

Well, I believe that an image should clearly convey the limits of its usefulness, if only with a link to a "fully explanation" article. Very few Monad tutorials do that, which I think is a shame. Also, my model has been pretty easy - it's a variation of associativity. "Variation" because the operands are functions, and the result type of a left operand needs to match the parameter type of a right operand. (That's why it's "pseudo"-associative). Now with these constraints, the most natural thing to do is function composition, possibly with sandwiches default functions. If the operand type is a rich parameterized type, it can do more, to the point that the overall semantics is dominated by the operators instead of what the operands do. I also don't know if there's anything practically useful on that path. And, of course, I may be totally misunderstanding what a monad actually is. All I know is that this variation-of-associativity model seems to fit the monad laws more closely than the pipeline model, so _if_ it is correct I'd find it more useful than the pipeline model, because it tells me what things beyond a pipeline I could do with it. Regards, Jo