5 ms·

The sequencing is described precisely in the signature of bind. (>>=) :: Monad m => m a -- Left argument -> (a -> m b) --

The sequencing is described precisely in the signature of bind. (>>=) :: Monad m => m a -- Left argument -> (a -> m b) -- Right argument -> m b You don’t need to explain an individual monad instance to notice that this signature requires “a” in order to generate “m b”.

tome 9y ago
What about the Identity monad? Does that "force sequencing"? What "sequencing relationship" does it create? If you are convinced that the Identity monad does "force sequencing" then you are also convinced that lazy evaluation "forces sequencing" (because the Identity monad is just lazy evaluation). That would be a fairly controversion conviction. If you are not convinced that the Identity monad "forces sequencing" then can you explain in more detail the meaning of your claim "What a Monad does is to force sequencing by creating a data dependency.".
- tree_of_item 9y ago
  The identity monad's sequencing is just basic cause and effect: you need to have produced an `a` in order to get a `b`. The sequencing is very obvious from the signature of `>>=`. You don't need to know anything about any instances to see that it's there.
  - tome 9y ago
    > The identity monad's sequencing is just basic cause and effect: you need to have produced an `a` in order to get a `b`. You most certainly do not! See https://news.ycombinator.com/item?id=16420742 https://news.ycombinator.com/item?id=16420742
    - tree_of_item 9y ago
      It's in the signature. `b` has a causal dependency on `a` because `a` is on the left hand side of the arrow and `b` is on the right hand side of the arrow. That's it. Functional programming 101. There's no way around this. The operational semantics and details of thunks are not relevant here. Tricks with `undefined` are not relevant here. This is just the meaning of the arrow type.
      - pdpi 9y ago
        If that were true, why do you need a monad for sequencing? Why doesn’t function composition suffice, or something of the form a -> (a -> b) -> b?
        tree_of_item 9y ago
        Because the values have extra "stuff" surrounding them. That's why it's `m a` and not just `a`: the `m` holds the invisible context that enriches the `a`. Although your example is exactly what's happening in the identity monad, because there is no extra stuff.
        gowld 9y ago
        Monads have been called "executable semicolons", because you can define a function to be executed each time the program passes from one statement to the next.
pdpi 9y ago
That's not quite right. Let's define an operator `|> = (flip $)`, which has a type signature `a -> (a -> b) -> b`, which, by your reasoning, should force sequencing too. Except it doesn't: Laziness is a bitch to work with, and `a |> f |> g` evaluates to `g(f(a))`, and g is evaluated first, which then evaluates f(a) on demand. If you consider `1 |> (+1) |> const 4`, this will evaluate to 4 without ever performing the addition. Instead, let's compare this to the monadic equivalent. `(return 1) >>= return . (+ 1) >>= return . (const 4)`. The sequence that's being forced here isn't that (+ 1) is evaluated, it's that 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. In IO world, this corresponds to guaranteeing that the IO operations happen in sequence irrespective of the order in which the pure computations they wrap are evaluated in.
- 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 ago
    Right — 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 ago
      Right! `>>=` 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!
jw- 9y ago
How is sequencing described in the type of join?

tome 9y ago

What about the Identity monad? Does that "force sequencing"? What "sequencing relationship" does it create? If you are convinced that the Identity monad does "force sequencing" then you are also convinced that lazy evaluation "forces sequencing" (because the Identity monad is just lazy evaluation). That would be a fairly controversion conviction. If you are not convinced that the Identity monad "forces sequencing" then can you explain in more detail the meaning of your claim "What a Monad does is to force sequencing by creating a data dependency.".

tree_of_item 9y ago
The identity monad's sequencing is just basic cause and effect: you need to have produced an `a` in order to get a `b`. The sequencing is very obvious from the signature of `>>=`. You don't need to know anything about any instances to see that it's there.
- tome 9y ago
  > The identity monad's sequencing is just basic cause and effect: you need to have produced an `a` in order to get a `b`. You most certainly do not! See https://news.ycombinator.com/item?id=16420742 https://news.ycombinator.com/item?id=16420742
  - tree_of_item 9y ago
    It's in the signature. `b` has a causal dependency on `a` because `a` is on the left hand side of the arrow and `b` is on the right hand side of the arrow. That's it. Functional programming 101. There's no way around this. The operational semantics and details of thunks are not relevant here. Tricks with `undefined` are not relevant here. This is just the meaning of the arrow type.
    - pdpi 9y ago
      If that were true, why do you need a monad for sequencing? Why doesn’t function composition suffice, or something of the form a -> (a -> b) -> b?
      - tree_of_item 9y ago
        Because the values have extra "stuff" surrounding them. That's why it's `m a` and not just `a`: the `m` holds the invisible context that enriches the `a`. Although your example is exactly what's happening in the identity monad, because there is no extra stuff.
        gowld 9y ago
        Monads have been called "executable semicolons", because you can define a function to be executed each time the program passes from one statement to the next.

pdpi 9y ago

That's not quite right. Let's define an operator `|> = (flip $)`, which has a type signature `a -> (a -> b) -> b`, which, by your reasoning, should force sequencing too. Except it doesn't: Laziness is a bitch to work with, and `a |> f |> g` evaluates to `g(f(a))`, and g is evaluated first, which then evaluates f(a) on demand. If you consider `1 |> (+1) |> const 4`, this will evaluate to 4 without ever performing the addition. Instead, let's compare this to the monadic equivalent. `(return 1) >>= return . (+ 1) >>= return . (const 4)`. The sequence that's being forced here isn't that (+ 1) is evaluated, it's that 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. In IO world, this corresponds to guaranteeing that the IO operations happen in sequence irrespective of the order in which the pure computations they wrap are evaluated in.

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 ago
  Right — 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 ago
    Right! `>>=` 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!

jw- 9y ago

How is sequencing described in the type of join?