A subset of function arguments are function colors because async/await is isomorphic to requiring and passing a `callback` arg around. It was named 'callback hell` because there wasn't an escape hatch and it affected every function in the callstack.
I'd venture to guess that there's a more abstract way of formalizing this in the sense that monad instances are required to be threaded through the callstack in particular cases(would love to see this spelled out formally) where IO and Cont(?) have this requirement but State like the author points out, does not.
I think this is a case where you want to avoid architecture astronautics and deal with languages as they are presented. Yes, in the end it's all continuation passing, or depending on the cut of your jib, it's all just assembler in the end, but meanwhile, down in the trenches, there are real, practical differences in color that change how you program in those languages, and that's the topic color addresses.
I cited the case of an argument color already in the text for Zig... in fact, that's conditionally a color depending on what is passed, which is even more sophisticated then an argument merely being unconditionally a color.
What some people want to do is call every argument a "color", that is, I changed this function to have to take a Username and now it's Username-colored is the claim. I supposed I should have made that more clear. This provides a definition where that is not the case.
Global context is absolutely a color. All global contexts are probably the same color, as you can put them all in one GlobalContext object and add new fields to that object, or no color if you make them global variables instead.
GetUserByUsername needing a username isn't a color because that's just what the function does, but GetFontSize needing the current username (to look up their preferences) is one if you don't make it a global variable.
Comments
A subset of function arguments are function colors because async/await is isomorphic to requiring and passing a `callback` arg around. It was named 'callback hell` because there wasn't an escape hatch and it affected every function in the callstack.
I'd venture to guess that there's a more abstract way of formalizing this in the sense that monad instances are required to be threaded through the callstack in particular cases(would love to see this spelled out formally) where IO and Cont(?) have this requirement but State like the author points out, does not.
I think this is a case where you want to avoid architecture astronautics and deal with languages as they are presented. Yes, in the end it's all continuation passing, or depending on the cut of your jib, it's all just assembler in the end, but meanwhile, down in the trenches, there are real, practical differences in color that change how you program in those languages, and that's the topic color addresses.
Their point was that if language async is a color, so are async callbacks, which are arguments, therefore arguments can be colours.
I cited the case of an argument color already in the text for Zig... in fact, that's conditionally a color depending on what is passed, which is even more sophisticated then an argument merely being unconditionally a color.
What some people want to do is call every argument a "color", that is, I changed this function to have to take a Username and now it's Username-colored is the claim. I supposed I should have made that more clear. This provides a definition where that is not the case.
Global context is absolutely a color. All global contexts are probably the same color, as you can put them all in one GlobalContext object and add new fields to that object, or no color if you make them global variables instead.
GetUserByUsername needing a username isn't a color because that's just what the function does, but GetFontSize needing the current username (to look up their preferences) is one if you don't make it a global variable.