I will test it on a couple of machines, desktops and laptops. Try using a sensible nonzero value with threadDelay. Apparently it brings CPU usage down under Windows while retaining smoothness. However, increasing it from zero results in jerkiness under Linux...
If you take a look what Yampa does: it hides signals and only exposes signal functions. But that means that the FRP engine itself could indeed use mutable variables for its signals, as long as during the evaluation of the circuit at time T no side effects should occur; the side effects should take place when the simulation is advanced to T+dT, which is done after the circuit is fully evaluated at time T. Assuming that everything works as intended, Elerea is indeed free of side effects. As for the underlying engine, I was also considering the Hume language, but it has an unpleasant property that every box (analogous to the signal functions of Yampa) has an implicit delay. In fact, Elerea can be regarded as some kind of delayless Hume if we squint enough.
I'm only a bit worried about your automatic insertion of delays; this might break referential transparency at time T, since it depends on the order in which the nodes in the circuit are evaluated no? The latter could be problematic when doing evaluation in parallel on multiple cores I guess. Oh, it's problematic enough even on a single core. ;) If the network changes at one place, it might affect evaluation order in a way that delays can start wandering around in dependency cycles far away. It could be interesting to analyse the effects of this behaviour. Either way, this is just a convenience feature for applications where it makes little difference. I was also thinking about providing two versions of the library: one inserting delays, and another giving an error instead.
By the way, it's also in the plans to visualise the network. Gergely -- http://www.fastmail.fm - IMAP accessible web-mail