Discussion on: The Quest for ReactiveScript

Interesting stuff. I wrote a language that I never got to implement (of course but who knows if one day I won't find the time to do it) that does what you suggest. The language is simple, and based on the core functional reactive programming concepts. You have events, effects, and pure computations. Excerpts:

-- events. Syntax: event => effect (here state update)
clickPlus => counter <- counter + 1
clickMinus => counter <- counter - 1

-- equations
unit_price = 100
price = counter * unit_price
...

-- effect. Syntax: event => effect
update(price, counter, ...) => render ...

So just three key elements of syntax, event => action notation to express reactions, = for equations that must always hold at any point of time (your const ?), and <- to update an equational variable.

There is nothing particularly smart there. Synchronous reactive languages are not much different than that (Lucid, Esterel, etc.). It is not the smartness, it is more the simplicity of the notation.

For composition, it is simply about noting that a program is a set of events (left side of x => y), variables (left side of x = y), and action/effect handlers (right side of x => y). So Program<Events, Variables, Effects> basically. To get one big Program from two small Programs, just import those two small in the big one and possibly rename the variables, events, effects (to avoid shadowing) - just like you would do with template partials in good old HTML templating systems. But the story was not perfect for composition. Renaming is a hassle that breaks a bit module independence (the big component that reuses the small one need to know about the details of the used component. Ideally you should not need to know about the variables in the reused component, they should be encapsulated).

Haven't put myself to solve these problems though. So it is interesting to read this writing.