Lambda the Ultimate

1. Yes, creating a binding is a simple imperative statement (this is still C#!). So

rect.position().bind = new Point(100,100);
rect.position().bind = new Point(200,200);

The latter statement is in effect (a signal can only be bound once).

Actually, this is a very simple wrapper around WPF's dependency properties. So in WPF, the current value of a dependency property is

(a) its default value,
(b) its bound value,
(c) its explicitly set value, and
(d) its animated value,

Where (d) has a higher priority than (a). Since signals here wrap dependency properties, they will provide whatever value is the current observed value of the dependency property. Actually, the signal library allows us to express (b), (c) and (d) ((a) can only be expressed when the dependency property is defined), e.g.,

// (d) move rectangle to 100,100 in 1 second
rect.position().animateTo(new Point(100,100));
// (c) make rectangle's position 100,100 NOW
rect.position().value = new Point(100,100);
// (b) ensure that rectangle's position is always 100,100
rect.position().bind = (new Point(100,100)).constant();

I prefer using mostly (b) in my programs, while animation originates from one animated "clock" signal. Priorities can be a pain sometime as animations remain in effect even after they have reached their destination value! For that reason, you can also "stop" an animated signal so you can set its value:

rect.position().stop();

You can clear the value of a signal so its binding will be used:

rect.position().clearValue();

Or you can clear a binding so the default value will be used:

rect.position().clearBinding();

A bit complicated because we are wrapping WPF vs. defining our own signal construct from scratch.

2.

The combinations I allow are very simple, there is no real constraint system. So for:

(o.a() + o.b() + o.c()).bind = o.d()

The value of o.d() - o.b() - o.c() will be stuffed into o.a(). If we rewrite the expression to have o.b() first, it will go in o.b() instead. This was done as a convenience so that we can write things like:

(rect.position() + rect.center()).bind = new Point(100,100).constant(); 

What is interesting is if you instead write:

(rect.center() + rect.position()).bind = new Point(100,100).constant(); 

Now, this is equivalent to

rect.center().bind = new Point(100,100).constant() - rect.position();

This would basically resize rectangle instead of repositioning to ensure that rect is still in the center!

3. we don't deal with collections yet. .NET has an observable collection class + there is LINQ. We might be able to build something on top of that. But for now there hasn't been a strong need. No Signal either, actually, I'm not sure if/how WPF can support that.

This is just for WPF (around dependency properties), the library could also easily be ported to Silverlight or Windows workflow/WWF (which are also based on dependency properties).

I didn't actually implement signals for C#, I'm just bringing out the best in dependency properties :)

I do most of my simple UIs in Flapjax nowadays (though perhaps largely because of $B !) - doing a stripped down version with browser testing wouldn't take too long.