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

[Joachim Durchholz]

Am 20.09.21 um 19:50 schrieb Viktor Dukhovni:
>> On 20 Sep 2021, at 2:30 am, Joachim Durchholz <jo at durchholz.org> 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