4 ms·

And I bet those green threads still need an IO type of some sort to encode anything non-pure, plus usually do-syntax. Comparing merely concurrent computations t

by debugnik 10mo ago

And I bet those green threads still need an IO type of some sort to encode anything non-pure, plus usually do-syntax. Comparing merely concurrent computations to I/O-async is just weird. In fact, I suspect that even those green threads already have a "colourful" type, although I can't check right now.

iviv 10mo ago
Pure actions can be run in parallel with https://hackage-content.haskell.org/package/parallel/docs/Control-Parallel.html https://hackage-content.haskell.org/package/parallel/docs/Co... Impure actions use the IO monad like always in Haskell: https://hackage.haskell.org/package/base-4.21.0.0/docs/Control-Concurrent.html https://hackage.haskell.org/package/base-4.21.0.0/docs/Contr... (or the higher-level async library) I suppose an extreme version of the function coloring argument could be that all types are colors.
- debugnik 10mo ago
  In a sense, kinda? The function colour problem is that you can't call an async API from a non-async caller without modifying the entire call chain (or blocking the full thread). In async/await languages the conflict comes from changing the return types; the syntax is orthogonal. Maybe in practice some properties of code are better off being whole-program than represented as types, even if they're less modular or harder to check. Also thanks for the reference, I haven't touched Haskell in ages; I'm more of an F# and OCaml guy.
  - iviv 10mo ago
    Right. In Haskell we want to maintain the pure/impure distinction so… it’s not a problem I guess?
instig007 10mo ago
> And I bet those green threads still need an IO type of some sort to encode anything non-pure, plus usually do-syntax. There's no need for the do-syntax at all. The (IO a) is no different to other generic types that can be fmap-ed, pointfree-composed with other expressions, and joined/folded when required. The only difference is the fact that they represent actions that affect the real world, so that ordering of things suddenly becomes important.
- debugnik 10mo ago
  Right, and there's also no need for await syntax at all, they can be then-ed, ContinueWith-ed or whatever the language calls them, but people keep bringing syntax into a semantics battle, so I had to mention it.

iviv 10mo ago

Pure actions can be run in parallel with https://hackage-content.haskell.org/package/parallel/docs/Control-Parallel.html https://hackage-content.haskell.org/package/parallel/docs/Co... Impure actions use the IO monad like always in Haskell: https://hackage.haskell.org/package/base-4.21.0.0/docs/Control-Concurrent.html https://hackage.haskell.org/package/base-4.21.0.0/docs/Contr... (or the higher-level async library) I suppose an extreme version of the function coloring argument could be that all types are colors.

debugnik 10mo ago
In a sense, kinda? The function colour problem is that you can't call an async API from a non-async caller without modifying the entire call chain (or blocking the full thread). In async/await languages the conflict comes from changing the return types; the syntax is orthogonal. Maybe in practice some properties of code are better off being whole-program than represented as types, even if they're less modular or harder to check. Also thanks for the reference, I haven't touched Haskell in ages; I'm more of an F# and OCaml guy.
- iviv 10mo ago
  Right. In Haskell we want to maintain the pure/impure distinction so… it’s not a problem I guess?

instig007 10mo ago

> And I bet those green threads still need an IO type of some sort to encode anything non-pure, plus usually do-syntax. There's no need for the do-syntax at all. The (IO a) is no different to other generic types that can be fmap-ed, pointfree-composed with other expressions, and joined/folded when required. The only difference is the fact that they represent actions that affect the real world, so that ordering of things suddenly becomes important.

debugnik 10mo ago
Right, and there's also no need for await syntax at all, they can be then-ed, ContinueWith-ed or whatever the language calls them, but people keep bringing syntax into a semantics battle, so I had to mention it.