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
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.
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...
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.
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]
The text was updated successfully, but these errors were encountered: