<div dir="ltr">I suspect a lot of people were pleased that they'd finally gotten rid of lazy Result -> Request.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 17, 2021 at 4:34 PM Joachim Durchholz <<a href="mailto:jo@durchholz.org">jo@durchholz.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 17.09.21 um 21:47 schrieb Viktor Dukhovni:<br>
> Personally [verbal sequential], I find strained analogies unhelpful<br>
> and distracting, so no desk clerks shuffling forms for me.<br>
> <br>
> I internalised Haskell monads, by implementing the Functor, Applicative<br>
> and Monad instances for Reader and State a few times from scratch.  Once<br>
> those were solid, ReaderT and StateT and their MonadTrans instances.<br>
> <br>
> Unsurpsingly, I have a mental model built around sequencing of internal<br>
> state updates while passing data from one state to use in choosing the<br>
> next state transition.<br>
<br>
I have been finding the Monad expositions misleading - that idea that <br>
monads are for sequencing or transitions or mutable state always felt <br>
wrong to me, since the monad laws don't talk about any of these things <br>
at all.<br>
<br>
And as far as I could understand the concept, monads are not about <br>
state, they're about "composing a linear sequence of functions". The <br>
functions' types need not be the same (that would degenerate into the <br>
concept of associativity), but the result type of one function must be <br>
the parameter type of the next.<br>
The monad can do whatever it likes with the functions - typically, wrap <br>
them in some other function and construct a function composition; there <br>
isn't much else you can do with them, though you're not doing much <br>
justice to the Maybe monad if you see it as a pipeline.<br>
Ah... right... and of course the pseudo associativity. I.e. it doesn't <br>
matter what parts of the total sequence you construct first.<br>
<br>
Of course, state transitions are a fine application of this concept.<br>
Or anything else where you see a function as a computation step and you <br>
want to run these steps in sequence.<br>
It's just that there are more kinds of monads.<br>
Except if you see Maybe as "do these operations in sequence until you <br>
hit the first that returns None, then abort". It depends on seeing <br>
functions as executable things though, and that's not really what <br>
Haskell is trying to be (or was trying to be 20 years ago, maybe <br>
everybody is now happy that Haskel finally can express imperative stuff <br>
via monads... no idea what people think)<br>
<br>
Regards,<br>
Jo<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>brandon s allbery kf8nh</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a></div></div></div></div></div>