I find Reactive.Signals extremely useful, especially for GUIs and in combination with Gtk à la GtkReactive.
To map one signal to another via some function we use Reactive.map. I can’t help but think that the resulting code would be much prettier if we didn’t need to use this ‘map’ syntax, but instead used the functions directly on the signals. For example, for x = Signal(π), y = map(sin, x) would simply become y = sin(x). Apart from the prettier syntax, I imagine that this could simplify existing functionalities and/or make non-existing ones available.
I was just thinking about that, I don’t think it is impossible…
I thought of also adding “silent” Signals … Signals that you cannot push into, and they do not update,
but they remember their inputs and if you derive a map from them it will result in a function of the silent signal inputs
which is active.
For example:
a = Signal(1.0)
b = Signal(10.0)
c = a-b #resulting type is silent signal
d = map(c) do x
x^2
end
#is equivalent to
d = map(a,b) do x,y
(x-y)^2
end
Ans also of adding a concept of data_age per node, that is a counter that increments every time the value of the node changes(actually changes) , this is useful for avoiding re-drawing in GUI for example , and it will allow to turn on and off the drop repeats feature.
and for a polling design pattern.
And I thought of adding the concept of sink/source and to allow only one sink/source per node … that is a node can only be the result of a single map.
with this then we can also have pro-active programming where you poll a node and it forces computation all the way to its sources.
we can still have binding but they will lower precedence when going back in the tree.
And I also thought of making each node remember its world_age and also the main event loop can remember its world_age, and whenever an action of a node with newer world_age shows up in the event loop then simply restart it.
So once the code finished loading and firing up a few times, the event loop is no longer re-started.
I also agree that it can be done, but it will have some rough edges. I did something like that with Sims.jl. Reactive variables and other symbolic types can combine in expressions. You have to manually define the functions that work with Reactive inputs.
What can be clumsy is that users will probably run into functions where this doesn’t work. My use case is a DSL where the scope is confined a bit, so this clumsiness isn’t too bad.
Another option is to define your own mini DSL with a macro that translates functions to use map.
Lastly, there’s been some talk in Base of a more concise syntax for anonymous functions. That would help here.