[seanmcdirmid]

If you only care about animation, why not just use a constraint solver like a physics engine? Time step is set st run-time, constraints are quite natural (springs to pull something in). Constraint programming provides the declarative data binding feel of FRP behaviors (someone on my committee pointed that out). What you don't get with constraint systems are event streams, but that isn't so useful for UI programming anyways.

We had this discussion a while back:

http://lambda-the-ultimate.org/node/2913

[tel]

I think that's a really great idea, too. The worrisome bit around constraint solvers is that they're really easy to get into strange "spooky action at a distance" states of constraint interaction which are incredibly tough to escape from. Building good constraints thus feels like something of a black art.

[seanmcdirmid]

Sticking to Newtonian rather than using quantum physics can avoid the spooky action at a distance problem (I know this isn't what you meant, but I couldn't resist).

Actually, constraints are quite explicit compared to imperative assignments.

[tel]

Ha, and I had to speak of it that way for the same reason.

I believe that constraints are explicit, but their cumulative effect is difficult to predict. A constraint which wipes out some part of the feasible space with lots of vertices can have sudden and dramatic (non-local) impact on the solution. If your solver is approximate or your solution non-linear it might be incredibly difficult to figure out where the solver will ultimately land.

[seanmcdirmid]

I have found Verlet integration with an implicit velocity to be really good in this regard. It doesn't conserve energy very well, but it is very easy to work with (predictable) when doing animations since constraints are expressed by updating particle positions directly. I wrote a half baked paper on this once:

http://research.microsoft.com/pubs/191705/uiphysics09.pdf

[tel]

I'll take a look; thanks!