You avoid function coloring. It’s a function parameter.
I have a problem with this wording, because function coloring is isomorphic to function parameters. It is fundamentally about how if you need thing X as a parameter at the bottom of the callstack, it will spread upwards. It doesn’t really matter whether the parameter is implicit or not. And it also goes for return types: if you introduce a Result at the bottom of your previously-infallible stack, it will start to spread upwards, unless you bite the bullet and unwrap it. Which will then unwind the stack so philisiphically it still does spread upwards, except implicitly and invisibly.
This is a very insightful observation, thanks. On a related note, effect systems seem to unify all three of these (function coloring, state parameters and error propagation) but I was never able to articulate why should they be related until reading your comment.
unless you bite the bullet and unwrap it
Or for async, block the current thread on the future.
I have a problem with this wording, because function coloring is isomorphic to function parameters. It is fundamentally about how if you need thing X as a parameter at the bottom of the callstack, it will spread upwards. It doesn’t really matter whether the parameter is implicit or not. And it also goes for return types: if you introduce a Result at the bottom of your previously-infallible stack, it will start to spread upwards, unless you bite the bullet and unwrap it. Which will then unwind the stack so philisiphically it still does spread upwards, except implicitly and invisibly.
score 1 · canonical
This is a very insightful observation, thanks. On a related note, effect systems seem to unify all three of these (function coloring, state parameters and error propagation) but I was never able to articulate why should they be related until reading your comment.
Or for async, block the current thread on the future.
score 1 · canonical