5 ms·

I still haven't seen a good "solution" to this "problem" for imperative style programming. Why the quotes? Because the functions have different signatures, thus

by Rapzid 2y ago

I still haven't seen a good "solution" to this "problem" for imperative style programming. Why the quotes? Because the functions have different signatures, thus different functions(colors). And IT MATTERS. That's why you have structured concurrency hot on the heels of Loom. And once you are using structured concurrency constructs... Ehh, it's not the magic "solution" we were sold anymore is it?

immibis 2y ago
The article is not about functions having different type signatures but being somehow fundamentally different. It occurs every time we try to qualify and enforce restrictions on functions, whether it's async, pure, nonblocking, or whatever. Although they aren't all harder to call, they always cause problems with higher order functions. An idea of "effect generics" tries to improve upon this - you write something like template<effect T> T_function List filter(List list, T_function pred) (element type committed for brevity) and then filter is async if the predicate is async, etc - it's pure if the predicate is, nonblocking if the predicate is. If you continue in this direction, your language gets more complex than C++. The other options are to just accept that you need a separate filter function for async and non async predicates, or to do away with function flags (doesn't work for CPS style async of course).
- Rapzid 2y ago
  This article is about exactly what I'm addressing. I stopped reading after your false premise.
HiJon89 2y ago
Not sure I follow. The function coloring problem is still solved in that scenario. You can apply structured concurrency to any function (there’s no colors), and any function can contain structured concurrency within it (ie, using structured concurrency doesn’t color your function)
- Rapzid 2y ago
  You don't follow. Nothing against you in particular, but this is why we've had 10+ years of "color problem" articles and no real solutions. The problem isn't the colors, it's the ergonomics. The naive solution doesn't work because it turns out the difference between functions that return a value and functions that return a promise matters.. The other approaches destroy ergonomics.

by Rapzid 2y ago

immibis 2y ago

The article is not about functions having different type signatures but being somehow fundamentally different. It occurs every time we try to qualify and enforce restrictions on functions, whether it's async, pure, nonblocking, or whatever. Although they aren't all harder to call, they always cause problems with higher order functions. An idea of "effect generics" tries to improve upon this - you write something like template<effect T> T_function List filter(List list, T_function pred) (element type committed for brevity) and then filter is async if the predicate is async, etc - it's pure if the predicate is, nonblocking if the predicate is. If you continue in this direction, your language gets more complex than C++. The other options are to just accept that you need a separate filter function for async and non async predicates, or to do away with function flags (doesn't work for CPS style async of course).

Rapzid 2y ago
This article is about exactly what I'm addressing. I stopped reading after your false premise.

HiJon89 2y ago

Not sure I follow. The function coloring problem is still solved in that scenario. You can apply structured concurrency to any function (there’s no colors), and any function can contain structured concurrency within it (ie, using structured concurrency doesn’t color your function)

Rapzid 2y ago
You don't follow. Nothing against you in particular, but this is why we've had 10+ years of "color problem" articles and no real solutions. The problem isn't the colors, it's the ergonomics. The naive solution doesn't work because it turns out the difference between functions that return a value and functions that return a promise matters.. The other approaches destroy ergonomics.