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

yield and eval behaviour #5

Open
JOT85 opened this issue Dec 1, 2019 · 2 comments
Open

yield and eval behaviour #5

JOT85 opened this issue Dec 1, 2019 · 2 comments
Milestone

Comments

@JOT85
Copy link
Member

JOT85 commented Dec 1, 2019

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?

@sharnoff
Copy link
Contributor

sharnoff commented Dec 1, 2019

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.

@JOT85
Copy link
Member Author

JOT85 commented Dec 2, 2019

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.

@JOT85 JOT85 added this to the 0.1.0 Spec milestone Dec 2, 2019
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

2 participants