On Wed, Nov 5, 2008 at 6:57 PM, Conal Elliott wrote:

The 'changes' function would break through the step-function-of-time semantics of Reactive. In other words, I don't think you can specify the meaning of 'changes' in terms of the meaning of Reactive.

I see what you mean: my implementation of changes only removes one kind of redundancy (reactive's simultaneous occurrences). It doesn't remove the redundancy where some occurrences may not change the value. My next thought is, why not add an Eq parameter to the changes function and use that to remove the other redundancy? I'm thinking that could work in many cases, but in this case: data WiperMode = Normal { singleWipe :: Event () , customWipe :: Event () } | SlowWipe | ContinuousWipe | FastWipe type WiperStick = Reactive WiperMode That would require me to have an Eq on WiperMode with the embedded events. I can't see a way to make that work. I think I'll just change my example to be WiperStick = Event WiperMode with a condition that there exists an occurance at -infinity. Hrm, I'm thinking this conversation should probably be on the reactive list. I'll cc it. David

- Conal

On Wed, Nov 5, 2008 at 1:47 PM, David Sankel wrote:

...

In this example (marked with the module it should go into).

http://hpaste.org/11766

Also, I've attached a patch to generalize the type of something.

David

-- David Sankel Sankel Software www.sankelsoftware.com