from armchair_progamer@programming.dev to programming_languages@programming.dev on 24 Mar 2024 17:10
https://programming.dev/post/11876418
We propose a new reactive programming language, that has been meticulously designed to be reactive-only. We start with a simple (first-order) model for reactivity, based on reactors (i.e. uninstantiated descriptions of signals and their dependencies) and deployments (i.e. instances of reactors) that consist of signals. The language does not have the notion of functions, and thus unlike other RP languages there is no lifting either. [emphasis added]
If you’ve ever used React hooks, you probably had at least one situation where you used them incorrectly and it led to subtle bugs. Maybe not even breaking your app, just causing it to re-render unnecessarily. React has lints for this, but they don’t cover all cases.
The fundamental problem is that React function components and hooks are an Embedded Domain-Specific-Language (EDSL) in JavaScript. They have their own semantics and control flow (e.g. changing a state value re-runs the function component, but code within certain “use” hooks only runs in certain situations), but they’re also manipulated with ordinary JavaScript (e.g. function components are just JavaScript functions, and state variables are just variables you can use in ordinary JavaScript expressions; the latter is what the authors mean by “lifting”). It’s very hard for developers to shift their mindset from reasoning about JavaScript to reasoning about React, and they (especially newcomers) very often conflate the semantics and do something “the JavaScript way” which in React, causes a slowdown or crash.
The authors’ solution is to make a fully reactive language which simply doesn’t have the functionality to write non-reactive code. To me, the examples look like ordinary code, but they compile directly into “reactor graphs” vs. a standard control-flow-graph that non-trivially encodes a reactive computation. I can only assume it’s much easier for a compiler manipulating the former type of graph to detect (if not simply avoid generating) problems like infinite loops and redundant computations.
Related, Facebook is working on a React Compiler. This still leaves React as an EDSL, so I don’t think it can eliminate all problems in the way this can, and it has to model JavaScript and React semantics which seems very hard to do correctly. But it does address the same problem while being much more practical; the compiler detects when something is improperly done “the JavaScript way” and either re-writes it or warns the developer.
threaded - newest
Another way forward is to limit oneself to pure total functions. This allows higher-order behaviors while still being “eventual reactive,” which improves upon the authors’ Haai language; higher-order Haai is only “weakly reactive.”