-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Evaluation Boundaries #22
Comments
mitchmindtree
added a commit
to mitchmindtree/gantz
that referenced
this issue
Jun 13, 2019
This allows for optionally specifying the full types of the inputs and outputs of a `Node` during implementation by allowing to specify a full, freestanding function, rather than only an expression. The function's arguments and return type will be parsed to produce the number of inputs and outputs for the node, where the number of arguments is the number of inputs, and the number of tuple arguments in the output is the number of outputs (1 if no tuple output type). Some of this may have to be re-written when addressing a few follow-up issues including nannou-org#29, nannou-org#19, nannou-org#21 and nannou-org#22, but I think it's helpful to break up progress into achievable steps! Closes nannou-org#27 and makes nannou-org#20 much more feasible.
mitchmindtree
added a commit
to mitchmindtree/gantz
that referenced
this issue
Jun 13, 2019
This allows for optionally specifying the full types of the inputs and outputs of a `Node` during implementation by allowing to specify a full, freestanding function, rather than only an expression. The function's arguments and return type will be parsed to produce the number of inputs and outputs for the node, where the number of arguments is the number of inputs, and the number of tuple arguments in the output is the number of outputs (1 if no tuple output type). Some of this may have to be re-written when addressing a few follow-up issues including nannou-org#29, nannou-org#19, nannou-org#21 and nannou-org#22, but I think it's helpful to break up progress into achievable steps! Closes nannou-org#27 and makes nannou-org#20 much more feasible.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In some cases it may be useful for some nodes to act as evaluation "boundaries". That is, traversal for push or pull evaluation cannot pass through the node. A couple examples that come to mind:
Delay
nodes require haulting evaluation so that it may be resumed again after a certain time period.StateSynchronisation
(or better name) nodes - @freesig's idea for synchronising evaluation between push and pull evaluation sources executing at different rates.Gate
s where ongoing evaluation might depend on some value (this might be more related to Conditional Evaluation #21).The text was updated successfully, but these errors were encountered: