3 ms·
When I've encountered colored functions(and here I'm specifically thinking of D's pure annotation) I have noticed that the architecture tends to collapse to the
by syntheweave 5y ago
When I've encountered colored functions(and here I'm specifically thinking of D's pure annotation) I have noticed that the architecture tends to collapse to the most permissive forms very quickly, because you will discover layers that were meant to encapsulate the coloration, and did "quack like it", but in a strict sense do not.
For example, one's expectations of a pure function would mean that you could do some arbitrary numeric computation on inputs and return a value. Unfortunately, the compiler is not so naive. If you should do some transcendental math and call a standard library function to do so, you have manipulated hardware state. You are now impure, and so are all your callees.
And so you have to decide at that point: is the code you are writing wrong? Or is it just using too coarse an assumption for its invariants?
A huge amount of what determines our code architectures are the way in which we've organized our own thoughts. In this respect we always go from looser to tighter specification over time as the code matures, until tightness has produced brittleness and cracks. I believe coloration forces some tightening decisions to be scheduled earlier. In that respect it should be treated with some suspicion, as it may produce surprising couplings.
- iamwil 5y agoHow come using transcendental math changes hardware state?
- adgjlsfhk1 5y agothey probably either set rounding modes or use x87 registers
- simulate-me 5y agoAdding colors without a concrete reason to do so will always be a waste of time. Take type checking as an example. If you use type A as a parameter that requires type B, your program will not work. Type checking provides a lot of value. Or in the GP’s example, forcing functions into async contexts ensures that, for example, the main UI thread doesn’t get blocked. The program will appear broken to the user if this rule is broken. Now compare this to pure functions. What happens if you break the pure function contract? Probably nothing. It’s still totally possible for the program to work. So you end up doing a lot of work that ultimately doesn’t change anything, which is what you’re observing with the proliferation of impure code.
- xigoi 5y agoIf a compiler assumes that a function is pure, while it's actually not pure, it may end up performing optimizations that break the logic, such as changing `x = f(); y = f()` into `x = f(); y = x`. And so might a human when refactoring.
- simulate-me 5y agoThis illustrates my point perfectly. Theoretical refactoring or optimizations are just hypothetical situations that may or may not occur. Needing to proliferate a function color incurs a real cost in terms of development efficiency. You should get something concrete if you pay the price. Until that happens, such language features are unlikely to gain widespread popularity.
- ketralnis 5y agoI think the x87 status/config registers you’re alluding to are a great example of power to the compiler that function colouring can potentially grant. “De-colouring” the function requires gating around preserving these registers but within that colour/monad there’s no need to preserve them. That’s an upside, not a downside
- simulate-me 5y agoThe CPU can do this at runtime and will likely do a much better job than the compiler.