You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To guarantee retrospective provenance without further user intervention, and simplify requirements on input channels (i.e. make it so only one input channel is necessary).
The outline is to replace the current While macro with a new While(Node) class in which the run functionality is overridden so it keeps instantiating new body and condition nodes as long as the condition is False. This is in analogy to how For clears its body and re-instantiates body nodes to accommodate the length of the input. As there, the while-node IO is static, but the internals lack prospective provenance in favour of having clear retrospective provenance.
From an implementation perspective, we would have a while_node method analogous to the for_node method that takes the body and condition classes, data on how the internal (looping) wiring should be, and returns a new dynamic While subclass. In this way, we never actually connect more than one output to the same input, although in a graphical scripting representation we might allow users to specify looping as though they are doing this.
The text was updated successfully, but these errors were encountered:
To guarantee retrospective provenance without further user intervention, and simplify requirements on input channels (i.e. make it so only one input channel is necessary).
The outline is to replace the current
While
macro with a newWhile(Node)
class in which the run functionality is overridden so it keeps instantiating new body and condition nodes as long as the condition isFalse
. This is in analogy to howFor
clears its body and re-instantiates body nodes to accommodate the length of the input. As there, the while-node IO is static, but the internals lack prospective provenance in favour of having clear retrospective provenance.From an implementation perspective, we would have a
while_node
method analogous to thefor_node
method that takes the body and condition classes, data on how the internal (looping) wiring should be, and returns a new dynamicWhile
subclass. In this way, we never actually connect more than one output to the same input, although in a graphical scripting representation we might allow users to specify looping as though they are doing this.The text was updated successfully, but these errors were encountered: