HN user
I think the solution to that is to have only a few builtin effects. This is the approach taken by the Verse language:
https://dev.epicgames.com/documentation/en-us/uefn/specifier...
It's a compromise between the granularity of correctness checks and readability, but IMHO it's still a big improvement over current type systems.
That would only work if the new versions were willing to break backward compatibility. The safety (and correctness) of a language is not about what it can do, but what it cannot.
Is there a public specification somewhere? The only thing I could find is the code in the "material-color-utilities" on github.
Looking at the code, it seems the computations are much more involved than OkLab, especially in the HCT -> RGB direction?
I don't think passing state through functions calls add cognitive load: it just make it visible. Global state has the same cognitive load, except hidden.
If a state is passed through dozens of function calls, this may indicate that it is shared by too many parts of the code, or that it is managed at the wrong layer of the architecture. When using global state, these potential problems are difficult to spot.
It's more complicated than that. The study referenced in the book found that snake_case makes variables easier to read, but the whole program harder to parse (my guess is it's because of the visual similarity between the underscore and a space). With camelCase, it's the other way around.
I vote for kebab-case, but I didn't find any study where it was included...
In order to know "what changed", you need at the very minimum to maintain a meta-state about your application state.
In most retained-mode GUIs, this meta-state is often a copy of a significant portion of your application state, but with a very different structure. To maintain the integrity of both copies, you then need a layer of events and/or listeners on top of that, with a complex and dynamic control flow.
Retained mode optimizes for display throughput, which matters a few decades ago. Immediate mode is better for latency and consistency, which are much more important now.
I believe the way it's usually done is to always parse a tuple, then parse the arrow as a binary operator applied to the two surrounding expressions. This potentially produce a syntactically incorrect AST (e.g. if there is an arrow following a tuple containing numbers), so you need to detect those in another pass and produce the corresponding error.