Friday, August 25, 2023

Simple reactive language idea

Here's my idea for a high level programming language in case I never get around to implementing...

Start with a really simple subset of a boring procedural language. I like python syntax, but it's not important.

Support reactive variables, aka cells aka FRP signals. Forbid reassigning globals except using a repl. Make that statically checkable.

a = 1
b = a + 2
//changing a to 4 automatically changes b from 3 to 6

Make functions use Mutable Value Semantics, for all parameters and return values. That is, have all values be semantically "pass by value", not just primitive values. So changing things inside a function has no affect on things outside of the function except for what the function explicitly returns. Make it relatively fast using persistent data structures.

Support working with individual members of a collection reactively. So, in addition to:

fuSprite = mouse.position + 2
//for a single sprite which follows the mouse

also support:

a barSprite = mouse.position + 2 on mouse.click
//multiple stationary sprites, with a new one created every time the mouse is clicked

(I haven't thought too much about the best syntax here. The word "a" or "an" in beginning is cute and english-y, but may be too much. I also don't know whether the trigger ("on mouse.click") should be before or after the expression. Also please forgive my handwavy introduction of events.)

Though the last pair of examples are GUI oriented, I'm dreaming of this language for general purpose use, including traditional server side code. I can't help thinking this is the "holy grail", a major step towards liberating programming from the von Neumann style. It's not an especially original idea, just a rejiggering of push-pull FRP for all non-local mutation, but I can't see why it wouldn't make programming dramatically simpler.

The major advantages are:

  1. Referential transparency - like in haskell but simpler
  2. Enhanced "view source" - anything you see on a computer, you could click and find out why, following the declarative trail all the way back to the first triggering events from outside
  3. True separation of concerns - this is only a hunch so far! I'm hoping that the more declarative approach could allow orthogonal implementation of genuinely useful features, like persistence or distributed consistency.