2 ms·

> Languages that don't make a syntactical distinction (such as Haskell) essentially solve the problem by making everything asynchronous What the heck did I jus

by debugnik 10mo ago

> Languages that don't make a syntactical distinction (such as Haskell) essentially solve the problem by making everything asynchronous What the heck did I just read. I can only guess they confused Haskell for OCaml or something; the former is notorious for requiring that all I/O is represented as values of some type encoding the full I/O computation. There's still coloring since you can't hide it, only promote it to a more general colour. Plus, isn't Go the go-to example of this model nowadays?

gf000 10mo ago
Haskell has green threads. Plus nowadays Java also has virtual threads.
- 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.

gf000 10mo ago

Haskell has green threads. Plus nowadays Java also has virtual threads.

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.