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
.fq and .fq.prettified show the initial input to LF. They contain liquid variables, and they are missing the equations discovered by ple and REST which are in (.fq.ple), and they miss the values assigned to liquid variables, which are present in .fq.out.
Navigating these files is possible, but probably it could be made simpler. I can imagine the following ways:
Use hypertext to jump to definition sites (of bindings, equations, matches, liquid variables, lists of PLE equalities for a particular constraint, etc) and back.
Consolidate all the information related to a constraint in one file. We would end up having one file per constraint, which might produce many files on some modules.
We could try to argue that we can just keep on with the files we have, since users aren't supposed to debug LH. However, once PLE or REST don't prove some constraint, the user will want to know what hypothesis are missing to prove it. And similarly, when working with abstract predicates, the user will want to know how the predicates are being inferred (maybe LH already can show this somehow?).
The text was updated successfully, but these errors were encountered:
We have a few dumps from different parts of liquid-fixpoint. There is
.fq
and.fq.prettified
show the initial input to LF. They contain liquid variables, and they are missing the equations discovered by ple and REST which are in (.fq.ple), and they miss the values assigned to liquid variables, which are present in.fq.out
.Navigating these files is possible, but probably it could be made simpler. I can imagine the following ways:
We could try to argue that we can just keep on with the files we have, since users aren't supposed to debug LH. However, once PLE or REST don't prove some constraint, the user will want to know what hypothesis are missing to prove it. And similarly, when working with abstract predicates, the user will want to know how the predicates are being inferred (maybe LH already can show this somehow?).
The text was updated successfully, but these errors were encountered: