3 ms·

> What about this? Is this even possible? > (T a -> b) -> T a -> T b Yep; that's the signature for the "extend" method of a comonad. https://hackage.haskell.

by Twisol 5y ago

> What about this? Is this even possible? > (T a -> b) -> T a -> T b Yep; that's the signature for the "extend" method of a comonad. https://hackage.haskell.org/package/comonad-5.0.8/docs/Control-Comonad.html#v:extend https://hackage.haskell.org/package/comonad-5.0.8/docs/Contr... Though I prefer the presentation with `duplicate :: w a -> w (w a)`, which is just the signature of Monad's `join` but flipped around.

WastingMyTime89 5y ago
> (T a -> b) -> T a -> T b That’s just a normal function application followed by return.
- bradrn 5y ago
  Not at all. There’s sensible implementations which aren’t like that. (You might as well say that (>>=) is just function application proceeded by ‘unwrap’.) My favourite example is cellular automata: if you have a data structure containing a grid along with a position on that grid, then that function signature corresponds precisely to running a cellular automaton on that grid. The idea is that the initial ‘T a -> b’ function is run for every single position, then all the results are combined into a single ‘T b’ grid.
  - WastingMyTime89 5y ago
    Except of course there is no unwrap in the actual definition while both application and return are sure to be there. It’s not like any of this is relevant anyway. The usual abstractions liked by Haskellers are utterly pointless as this whole discussion nicely demonstrate.
    - Twisol 5y ago
      > Except of course there is no unwrap in the actual definition while both application and return are sure to be there. The actual definition of what? `return` is not part of the Comonad class, while `unwrap` (alternatively called `extract`) is not part of the Monad class. No matter what your preferred way of designing abstractions, it seems a strange complaint to say "feature X is useless with abstraction Y" if you don't have a Y in the first place. > It’s not like any of this is relevant anyway. The usual abstractions liked by Haskellers are utterly pointless as this whole discussion nicely demonstrate. Well, okay then. You may not find value in this way of thinking, but other software developers -- many of whom, yes, ship actual software with actual business value -- find these ideas extremely valuable in organizing their thoughts about the problem domain. I'm open to sharing that mindset with anyone of a curious mind, but most of us aren't going to shove it down your throat. You're welcome to do what works for you.
- thewakalix 5y ago
  You might as well say that `(a -> T b) -> T a -> T b` is extract followed by normal function application.
  - bradrn 5y ago
    Huh, interesting how we came up with nearly identical comments at the same time! (Though I somehow managed to get the function name wrong…)
- Twisol 5y ago
  The important missing context is that a monad has `(return, bind)`, while a comonad has `(extract, extend)`, and both have their own respective laws letting you reason about combinations of those operations. You can certainly do what you describe if you have a monad, but since you can't even try to unwrap a value if you don't know what the monad is concretely, you have no way to write a function `T a -> b` that's generic over T. Functions `T a -> b` only really make sense for comonads, which give you the `extract` and `extend` functions as primitive.

by Twisol 5y ago

WastingMyTime89 5y ago

> (T a -> b) -> T a -> T b That’s just a normal function application followed by return.

bradrn 5y ago
Not at all. There’s sensible implementations which aren’t like that. (You might as well say that (>>=) is just function application proceeded by ‘unwrap’.) My favourite example is cellular automata: if you have a data structure containing a grid along with a position on that grid, then that function signature corresponds precisely to running a cellular automaton on that grid. The idea is that the initial ‘T a -> b’ function is run for every single position, then all the results are combined into a single ‘T b’ grid.
- WastingMyTime89 5y ago
  Except of course there is no unwrap in the actual definition while both application and return are sure to be there. It’s not like any of this is relevant anyway. The usual abstractions liked by Haskellers are utterly pointless as this whole discussion nicely demonstrate.
  - Twisol 5y ago
    > Except of course there is no unwrap in the actual definition while both application and return are sure to be there. The actual definition of what? `return` is not part of the Comonad class, while `unwrap` (alternatively called `extract`) is not part of the Monad class. No matter what your preferred way of designing abstractions, it seems a strange complaint to say "feature X is useless with abstraction Y" if you don't have a Y in the first place. > It’s not like any of this is relevant anyway. The usual abstractions liked by Haskellers are utterly pointless as this whole discussion nicely demonstrate. Well, okay then. You may not find value in this way of thinking, but other software developers -- many of whom, yes, ship actual software with actual business value -- find these ideas extremely valuable in organizing their thoughts about the problem domain. I'm open to sharing that mindset with anyone of a curious mind, but most of us aren't going to shove it down your throat. You're welcome to do what works for you.
thewakalix 5y ago
You might as well say that `(a -> T b) -> T a -> T b` is extract followed by normal function application.
- bradrn 5y ago
  Huh, interesting how we came up with nearly identical comments at the same time! (Though I somehow managed to get the function name wrong…)
Twisol 5y ago
The important missing context is that a monad has `(return, bind)`, while a comonad has `(extract, extend)`, and both have their own respective laws letting you reason about combinations of those operations. You can certainly do what you describe if you have a monad, but since you can't even try to unwrap a value if you don't know what the monad is concretely, you have no way to write a function `T a -> b` that's generic over T. Functions `T a -> b` only really make sense for comonads, which give you the `extract` and `extend` functions as primitive.