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

Define and handle partial evaluation (with unknown free variables from the context) #1640

Closed
Tracked by #1586
marijetamh opened this issue Sep 28, 2023 · 2 comments
Closed
Tracked by #1586

Comments

@marijetamh
Copy link

marijetamh commented Sep 28, 2023

As a second step toward #1586, and a follow-up of #1639, the next step to get contract checked in the LSP is to properly define partial evaluation (evaluation which supports having unknown free variables) and implement it.

Partial evaluation is necessary to handle partial configuration, which are the go-to idiom to write reusable configuration in Nickel. As a precedent, nickel doc is doing a form of evaluation that might fit: we recursively descend into record fields and evaluate them, without reporting missing field error. Doing so, we just ignore the part that we can't yet evaluate, but we still evaluate the rest, and report potentially several contract errors or evaluation errors at once.

From there, we can refine the notion of partial evaluation to handle more cases, if we discover common cases that aren't handled by this simple approach.

[edit: @yannham]

@jneem
Copy link
Member

jneem commented Mar 11, 2024

This is at least partly done by #1814, with the new eval_permissive function. It doesn't handle unknown free variables, but I'm not really sure of the motivation there. Is the idea to improve performance by being able to eval in the "middle" of the tree without starting from the root? If so, I think it might be better to focus effort on improving incrementality instead...

@yannham
Copy link
Member

yannham commented Mar 12, 2024

I think unknown free variables is a misleading wording. I originally mostly mean fields without definition, as encountered in partial configurations. To the best that I can judge, I think this issue is closed by #1814, as is the parent #1586. There are always possible improvements, in which case we should open new issues.

@yannham yannham closed this as completed Mar 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants