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
Currently in v0.1, a parameter's arguments wait to be computed until it's first used. Especially in the case of the lazy parameter {...}, unused parameters won't have their arguments calculated, saving on unnecessary computation.
However, this blocks a few desired features:
1. Avoiding re-calculation of independent parameter
See #3. Having a gap between a parameter's declaration and when its arguments are calculated means dependence between parameters can't be tracked, making it impossible to add an optimization for re-using an arguments iterable. Immediately calculating the arguments would enable this optimization
2. Parameters that are only used after the iteration completes
See #10. There is reason to calculate arguments even if the parameter isn't used by the time the iteration completes. So if arguments are going to be calculated anyway, then that might as well happen right away as that's most intuitive. That would break the current behavior, but if we need the argument, the options are break the current behavior and compute them at a different time, or keep the current behavior and slip the computation in at the end. Which... would be both unintuitive and needlessly complicated with no real benefit.
This will make it possible to avoid re-calculating independent parameters, enable captured parameters be used only after an iteration completes, and iterate arguments closer to their declaration. See issue #11 for context.
The code was minimally modified to change the behavior, and tests were changed to account for arguments iteration in declaration order instead of usage order (since that's now the order arguments are calculated and depend on each other).
This will make it possible to avoid re-calculating independent parameters, enable captured parameters be used only after an iteration completes, and iterate arguments closer to their declaration. See issue #11 for context.
The code was minimally modified to change the behavior, and tests were changed to account for arguments iteration in declaration order instead of usage order (since that's now the order arguments are calculated and depend on each other).
This will make it possible to avoid re-calculating independent parameters, enable captured parameters be used only after an iteration completes, and iterate arguments closer to their declaration. See issue #11 for context.
The code was minimally modified to change the behavior, and tests were changed to account for arguments iteration in declaration order instead of usage order (since that's now the order arguments are calculated and depend on each other).
Currently in v0.1, a
parameter
's arguments wait to be computed until it's first used. Especially in the case of the lazyparameter {...}
, unused parameters won't have their arguments calculated, saving on unnecessary computation.However, this blocks a few desired features:
1. Avoiding re-calculation of independent
parameter
See #3. Having a gap between a parameter's declaration and when its arguments are calculated means dependence between parameters can't be tracked, making it impossible to add an optimization for re-using an arguments iterable. Immediately calculating the arguments would enable this optimization
2. Parameters that are only used after the iteration completes
See #10. There is reason to calculate arguments even if the parameter isn't used by the time the iteration completes. So if arguments are going to be calculated anyway, then that might as well happen right away as that's most intuitive. That would break the current behavior, but if we need the argument, the options are break the current behavior and compute them at a different time, or keep the current behavior and slip the computation in at the end. Which... would be both unintuitive and needlessly complicated with no real benefit.
3. Iterating arguments upon declaration
See #12.
The text was updated successfully, but these errors were encountered: