This is a follow up post to Natural Async Programming
Giving my thoughts more thought, I realized a concept that could change everything. Something that OOP did for the Macintosh era, could do for our era–the async revolution. I looked into some things such as Flapjax and Elm, and I discovered an idea that I’d like to define in this post, signals. Not signals in the Elm sense specifically, but signals in my own definition.
First, let’s talk about event emitters. Event emitters can emitter any number of events, and handlers can be attached to these events and be invoked when the events are emitted. This is very powerful, but in JS, this is all done with callbacks:
Now, I’d like to define a signal as a lower level form of event emitter, but rather than a collection of events, it is a single event, a single signal. Signals, however, are not done with callbacks. They’re handled automatically by the interpreter:
var signal = createSignal();
data = signal;
createSignal is just an example of a function that would create a new signal; signals are more ubiquitous that having a single interface for creating signals, i.e. an async function could return a signal.
The idea is that a signal is a value that changes over time. The value is used as you would any value, but the code is re-evaluated when the signal changes. This is analogous to an event being emitted.
data is a signal too; everything is a signal! Just like in OOP, everything is an object, in SOP (signal oriented programming) everything is a signal!
But if everything is a signal, then wouldn’t this get confusing when everything is changing? No, because some signals are static, and don’t change. If I create a function that just returns the number 23, that’s a static signal.
Back to the comparison to signals and event emitters. Event emitters in a signal-based language would just be a collection of signals:
These signals can change, reacting to these signals is as simple as just using them. But, sometimes you’ll want to be able to just do something when a signal changes. Well, you just use the signal, and that code will be evaluated on signal changes. So you could just do an if statement:
Though, sometimes in JS, you might have callbacks that don’t have values passed to them (like setTimeout/Interval). In these cases,
if (signal) would evaluate to false because the value would be undefined in the signal. To solve this, there should be a statement just for handing signal changes:
It doesn’t have to be named
when, it could be named
Signal-oriented programming allows us to use all the power that functions give us but without the functions! Instead you just declare what happens in your program and when your program has signal changes, it responds. It’s a very enticing idea, isn’t it?
But, sometimes you don’t want to respond to a signal any longer. Take setInterval for example. If you had a similar function,
interval that takes an integer for milliseconds as input and returns an
undefined value for every signal change on that interval, you wouldn’t be able to clear this interval because there is no ID number to use to clear it. However, there is the signal itself, so all you need is a function that could kill the signal:
var intervalSignal = interval(1000);
var num = Math.random();
if (num*100 < 23)
The kill function will deallocate/garbage collect anything that is envolved with a signal. This function is probably unnecessary, because you could just use
delete to delete the variable itself, but maybe
kill() can do something more that
delete doesn’t do (i.e. stop all variables that reference the signal from receiving changes, or maybe keeping the value of the signal without allowing it to change further).
In conclusion, I think the idea of Signal-Oriented Programming should be the next hot topic for programming language semantics. I personally think, signals, or something like it, could change the way we program, and the way we think about how computers work, forever.