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
Interfaces without interleaving #1770
Comments
Adding another usability issue with the current interleaving semantics. When verifying the implementation of a module, the interface file is re-checked as part of the interleaving. This means that the recommended incremental-build style will effectively run queries for typechecking
|
Ambitiously tagging this for the V1 release. |
Ran into this again today. Particularly the issue mentioned by Jonathan here #1142 (comment). EDIT: Though actually in my case it was more like: fsti: val join : int -> ...
val something_else : ... -> Lemma (join 42 ....) fst: let join = ...
...
open FStar.Tactics
...
let something_else = .... And the error was that |
Is this really achievable in a few weeks? |
Is there any progress/planned work on this? We're running into issues with |
We haven't started working on this so far, but it's pretty high in our to-do list. I think the reason for that (bandaid) patch you mention was that if an interface has something like: #set-options "--fuel 0 --ifuel 0"
val f : ... Then the fuel setting can leak into the definition of Maybe a bigger bandaid is to keep two pragma states, so fst and fsti won't affect each other, and just interleave everything. |
Thanks for the reply, I see the point in doing it like that. Plus it's good to hear that this will be tackled 👍 In our case, we were indeed able to work around the problem by setting higher (i)fuel and resources in the |
In #959 @fournet summarized a few usability issues with interface files.
In a comment, @nik made a good proposal to do away with the interleaving semantics that would make them much more usable. For visibility, I'm making this an independent feature request and copying Nik's comment below.
See also this outstanding PR that describes other usability issues with pragma directives and open namespaces in interfaces.
The text was updated successfully, but these errors were encountered: