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
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:
eval x
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:
eval x -> a b
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?
The text was updated successfully, but these errors were encountered:
yield should behave like one would expect return to, where nothing is evaluated within its rule afterwards.
Maybe only allow it on the last line of a rule?
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
I don't like this but I don't immediately see a better solution. This one seems like it'll get overly verbose but I do think the body of the rule is the best place to evaluate.
I'm overall in favor of the idea of eval syntax, but I think it should be done carefully.
yield should behave like one would expect return to, where nothing is evaluated within its rule afterwards.
Maybe only allow it on the last line of a rule?
I'm not sure about that, as you might want to yield within conditionally executing code.
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
I don't like this but I don't immediately see a better solution. This one seems like it'll get overly verbose but I do think the body of the rule is the best place to evaluate.
I'm overall in favor of the idea of eval syntax, but I think it should be done carefully.
Cool, we can see how the suggested syntax works out and make changes if we feel like it needs it.
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.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 variablex
may 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 evaluated
error 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@y
notation and then the form ofeval
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:
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?
The text was updated successfully, but these errors were encountered: