Skip to content
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

Open
mitchmindtree opened this issue Mar 25, 2019 · 0 comments
Open

Evaluation Boundaries #22

mitchmindtree opened this issue Mar 25, 2019 · 0 comments

Comments

@mitchmindtree
Copy link
Member

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.
  • Gates where ongoing evaluation might depend on some value (this might be more related to Conditional Evaluation #21).
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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant