Higher-order signals and equality

[dbuenzli]

One of the annoyance of working with higher-order signals (i.e. signals carrying signals or events) is that the eq parameter has to be specified explicitly in the combinators that carry these values with ( == ), otherwise update steps will fail now and then with a hard to track down:

 Exception: Invalid_argument "equal: functional value".

We could provide two module Se, Ss that specialize the combinators for signals and events using S.Make. But this is similar to have to write eq:( == ) you need to remember you need to use this alternate set of combinators for such signals and this puts an unwanted burden on the programmer.

I'm not sure something can be done (well implicits, I'm not sure I like the idea of implicits but in that case that would solve it). The problem is that interesting FRP programs are higher-order.

[dbuenzli]

Possible (bloody) hack:

1. Add an uid in the first field of emut and smut values, this takes care of distinguishing non equal values.
2. Catch Invalid_argument on equality testing and return true, as it means 1. will have deemed the values equal.

Problem is that this will affect all possible other 'a values that could be carried by signals, not only signals and events. OTOH these would also raise in such cases. This means that any 'a value that is not able to distinguish itself before hitting a functional value in its structure will be deemed equal by react. We could also do it only when the default ?eq is used.