But expressions that use unsafePerformIO might get inlined. That's true, but given the way this interface is used, this doesn't seem to be an issue, since there are typically no unsafePerformIO's hidden deep inside an expression without a chain of Elerea primitives leading to it.
What about evaluation time? If I remember correctly, the values of signals depend on the time when the signal expressions are evaluated. So evaluating them multiple times might lead to different behavior. Is this correct? It is. However, there is really only one construct that needs extra care here: the latcher. All the others create top-level nodes that get evaluated just once during the first attempt to sample the output of the network. Therefore, duplication and merging of identical expressions only affects the performance unless they are hidden in the input signal of a latcher.
But in contrast to ordinary values, you have an internal mutable state, don’t you? Yes. But the access patterns are quite restricted, which makes things a bit easier to reason about. I can refer to the Hume language again: it stores state in mutable variables, but restricts each of them to have exactly one consumer and one producer, and the movement of data is also strictly regulated. Elerea lifts some restrictions of Hume: a variable can have many consumers, and nodes have no obligatory delays, so a piece of data can travel through the whole network in a single superstep. It still seems to be tractable, but no guarantees yet.
In the end it boils down to getting the latcher to evaluate the inner signal at the first moment too. This is easy to do with just top-level latchers (it takes a single seq at the right place), but latchers embedded in latchers can only be guaranteed to work if the inner signal is not just evaluated but sampled too (an extra call to signalValue). Which is probably what should be done anyway. If all these precautions are taken, the resulting networks should be equivalent with respect to superstep, which is the only way to look at their output. Nevertheless, I'm trying to find ways to create the network in a safer way without sacrificing flexibility on the user end. In the meantime, I'm silently analysing the consequences of the current design to see where and how it can break. Gergely -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html