This issue is to discuss the behaviour of the yield and eval directives.
yield behaviour
yield x, y, z, ... marks x, y, z, ... as the values to be yielded from a rule.
yield should behave like one would expect return to, where nothing is evaluated within its rule afterwards.
eval syntax and usage
When a compiler variable is obtained using matching (aka x@<rule> in the rule pattern definition), the variable x may not be used until it is evaluated by the use of eval as such:
For example:
rule the_world: "do " x@expr " after " y@expr {
# Neither x or y can be used here, and their directives have't been run, so any side effects have not yet occurred.
eval y
# y can now be used. The instructions for the pattern of y were effectively inserted where eval y is, so that's when its side-effects occur.
# x still cannot be used.
eval x
# x can now be used. Its side effects happened where eval x is, notably after y.
}
If a variable is used before it is evaluated, a useful x has not been evaluated error message can be used.
The only objection I have to this, is if multiple values are yielded as in the next example:
rule the_universe: "do " (a, b)@expr2 " after " (x, y)@expr2 {
eval x
# eval x must imply the evaluation of y, since to yield the value of x the value of y must also be yielded. This isn't very readable...
eval a b
# this syntax could be used instead, but I'm not a fan.
}
An alternative could be to make an entirely new type of thing! An evaluatable?
An evaluatable could be on the left of x@y notation and then the form of eval could be:
Where the number of destinations on the right is the same as the number of values yielded from x.
This would make the example above:
rule the_multiverse: "do " T@expr2 " after " U@expr2 {
eval U -> x y
# U is evaluated, and it's yielded values can be referenced with x and y.
eval T -> a b
}
I think I like that.
We should also not force an evaluatable to be evaluated - so it would not be an error to never evaluate T.
Thoughts?
This issue is to discuss the behaviour of the yield and eval directives.
yield behaviour
yield x, y, z, ...marksx, y, z, ...as the values to be yielded from a rule.yieldshould behave like one would expect return to, where nothing is evaluated within its rule afterwards.eval syntax and usage
When a compiler variable is obtained using matching (aka
x@<rule>in the rule pattern definition), the variablexmay not be used until it is evaluated by the use of eval as such:For example:
If a variable is used before it is evaluated, a useful
x has not been evaluatederror message can be used.The only objection I have to this, is if multiple values are yielded as in the next example:
An alternative could be to make an entirely new type of thing! An
evaluatable?An evaluatable could be on the left of
x@ynotation and then the form ofevalcould be:Where the number of destinations on the right is the same as the number of values yielded from x.
This would make the example above:
I think I like that.
We should also not force an evaluatable to be evaluated - so it would not be an error to never evaluate T.
Thoughts?