3 ms·
> the `return` in `return 1` is evaluated (producing a 1) before `return . (+ 1)` is ever touched, and that _that_ return is evaluated (presumably producing an
by tome 9y ago
> the `return` in `return 1` is evaluated (producing a 1) before `return . (+ 1)` is ever touched, and that _that_ return is evaluated (presumably producing an unevaluated thunk for (1 + 1)) before `return . (const 4)` is touched.
That's not quite right either. The former returns need never be evaluated.
> undefined >>= (return . (const 4)) :: Identity Int
Identity 4
- pdpi 9y agoRight — I should've said "that's the mechanism through which the implementation of `>>=` can force sequencing". `>>=` for Identity doesn't, most of the other common ones do, in some sense or another.
- tome 9y agoRight! `>>=` can force sequencing. It doesn't for Identity, Writer.Lazy or State.Lazy, but it can. OK, but also Arrow and Monoid can enforce a (different sort of) sequencing relationship. Neither does monad force a sequencing relationship nor is it the only thing than can force a sequencing relationship so I can only conclude that "What a Monad does is to force sequencing by creating a data dependency" is indeed one of those misconceptions!
- lmm 9y agoThat's just Haskell's crazy evaluation semantics though, not something that applies to monads in general.
- tome 9y agoIndeed. But bad_user made a claim about monads in general ("What a Monad does is to force sequencing by creating a data dependency.") so all I need to do to refute it is give an example of a particular monad where the claim doesn't hold.
- lmm 9y agoMonads force a denotation of sequencing. Of course you can write a language implementation where the sequencing of operation does not represent the sequencing of denotation (just as you can write a "compiler" that compiles all programs to Hello World), but, well, that's on you.
- tome 9y ago> Monads force a denotation of sequencing Aha! Now we're on to something.