Proposal: inactive edges

[Laszlo Pandy]

Thanks to Jeff's awesome and clear presentation for inspiring this proposal. This is exactly what the workshop was meant to do.

https://docs.google.com/a/prezi.com/document/d/1puyC2j9LtGHmI1pNqCuDpplknxsqHyOVgEowQi2Vp4o/

Feedback is much appreciated.

Thanks.

[Thomas Bereknyei]

I like it. Optimization that is invisible to the user and reduces uneeded computation.

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jeff Smits]

Thank you for the praise :) When you explained this during the discussion, I was so excited :D I'd tried to think of something like this myself, but couldn't figure it out.

I think your proposal would benefit from a few notes of the behaviour of your extra [upward] messages in the context of the theoretical model. I just mean something as simple as deactivated edges should not receive new Change/NoChange messages from a node; if an output edge of a node is activated, the node should send the most recent value as a Change message or a NoChange message if it didn't change since the last deactivation of the edge. Please correct me if these are not the semantics you have in mind. (Or rather, rephrase how you see fit anyway because I see these example notes are not very clear)

If they are, they bring me to the question of whether a node should for each individual output signal have a boolean value on whether the value of the node has changed since that edge got deactivated (or something like that). I may be thinking of too complicated solutions here, but I think this checking what to send down a reactivated edge may be non-trivial.

Another thing you might consider is the effect of the overhead of deactivating/activating edges in a concurrent setting (I know that's for the future, but it's still nice to think about it already). It may be a very small overhead, but consider your code example at the start of the document. Now make that time signal an every (second/120). The keepWhen switches the time signal on and off very rapidly. Do you think the on-off switching will be able to keep up and do something useful?

Personally I think is those kinds of situations may require a heuristic like waiting a certain amount of time before shutting of edges. Something like having a filter wait for an x milliseconds to see if the "filterOn" signal doesn't change too rapidly.

Can't think of anything else right now. It's a great idea and a well written proposal. Especially the updateValue for things like sampleOn is a nice touch!

--