-
Notifications
You must be signed in to change notification settings - Fork 380
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
[ elab ] Make %runElab
expressions have unrestricted quantity
#2021
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if you write an elab script that returns \x => x
at type (0 _ : a) -> a
?
Are you able to use it to implement
escape : (0 _ : a) -> a
escape = %runElab myscript
?
No! I've changed rig of input of This code escScr : Elab $ (0 _ : a) -> a
escScr = check $ ILam EmptyFC M0 ExplicitArg (Just `{x}) `(a) `(x)
esc : (0 _ : a) -> a
esc = %runElab escScr expectedly gives an error:
And even declaration like escDecl : Name -> Elab Unit
escDecl name = declare [
IDef EmptyFC name [
PatClause EmptyFC
-- lhs
(IApp EmptyFC (IVar EmptyFC name) (IBindVar EmptyFC "x"))
-- rhs
`(x)
]
]
%runElab escDecl `{esc} expectedly fails with
while expectedly typechecking for 0 esc' : (0 _ : a) -> a
%runElab escDecl `{esc'} I can add those above as an additional test case. |
1f45f78
to
76f3b3b
Compare
I disagree that bringing erased values to non-erased context should be impossible for elaboration scripts. Moreover, they should sometimes do this in some sence: consider an elaboration script for derivation of default That's why I think your test that expects "escaping" to fail, should not pass. The fact that it passes looks like a bug to me. Moreover, I ran into similar bug when during quoting instead of passed value a part of elaboration script was quoted. But for now I didn't manage to make a minimal example showing this for reporting as an issue. This bug seems to appear when Anyway, this bug is irrelevant to this PR. |
@buzden I'm not sure what you are replying to but I think I can bring in some intuition about what is happening with erased quantities. Especially your statement
erased means the value never appears at runtime, that also means that it should be allowed to be used at compile-time just fine. Since elaborator scripts are executing at compile time it feels natural to expect them to have access to erased multiplicity values. However, the values they have access to cannot be part of computations that appear at runtime. Think of the following example:
you wouldn't expect this program to typecheck, but you would expect the following to work
The only difference between those two programs is that we have inlined the call to
Like every complex issue, the real answer is "it depends", what this tree operation represents is "a program that is executable at compile type but might result in a different runtime representation". Because the runtime representation is changed the multiplicty cannot be TBD if something like that ever shows up (I'm working on it but I have also lots of other things going on :)). In the meantime, making PS: If you want the explanation without runtime/compile time intuition, page 3 of the QTT paper, the |
@andrevidela Thank you for the detailed elaboration on this. Let me just clarify that my original sentence had the meaning that I personally agree with the first position you list, i.e. I personally think that
Now I see that there is another opinion, it was not obvious. I thought of erased values not as those which are prohibited to be at runtime, but as those which by default are not present at runtime (but could if something forces this). After your brought both options explicitly, I've thought that maybe we need two kinds of elaboration scripts, of "safe" and "unsafe" flavours, one being unable to bring erased values to runtime, the other being able to do so. The problem is amplified by the fact that elaboration scripts can produce values that are meant to be present only at runtime, as it's shown in #2088. My mistake was to start this discussion in this PR because this PR does not change what is accessed to elaboration script during |
I think this change blurs / is due to a blurring of the line between erased values and staging. |
Sorry for the late reply, in my experience with QTT and different semantics for quantity semirings there is a clear distinction between staging semantics and use semantics. It is true that the waters are muddied for things like elaborator reflection but what this indicates is that more research is needed in order to make things work correctly. @buzden I suggest we talk about this on discord, I have a lot of work in progress in this area and we can probably find a middle ground between what we need to provide as a toolkit and what is an acceptable feature in terms of type safety |
3ae7ce0
to
2d3a97f
Compare
2d3a97f
to
297ca96
Compare
20718fd
to
2c9bf24
Compare
297ca96
to
deee51f
Compare
deee51f
to
c1dbf8a
Compare
Okay I think I have come around to this. Particularly because
Once the merge conflict has fixed I am happy to merge it. |
bfc90b4
to
10f3237
Compare
I tried to fix the evaluation issue we are getting in elab-util |
What do you mean? Do you mean you didn't find the cause? A couple of experiments from me: I changed existing Then I added every namespace from |
10f3237
to
dfe6f0e
Compare
Sorry, my wording was poor: I could not find a fix for the build issue. |
Fresh news! I found out that this non-reducing behaviour happens only in
|
Very interesting. The main code for the typechecking phase is in Could it be that a hole was delayed and we hit it in |
Once I allowed typechecker to see all imports publicly and I indeed got |
e79afbc
to
491629c
Compare
de82e35
to
759f227
Compare
759f227
to
584eb1e
Compare
584eb1e
to
3a2c41c
Compare
Just for a record: the reason of this quantity-related behaviour of underreduction is found by @AlgebraicWolf, but it is not obvious how to make all this work without reducing too much. The problem and directions of solution have been discussed on the latest weekly meeting in Discord, and are investigated at the moment. |
According to #1436, we can't have a runtime-values of types like
forall a. List a -> Nat
. But consider we need to pass a list of types including one like above to an elaboration script. Now we don't have such an ability. This PR enables it.Anyway, elaboration scripts work during compilation, why not them to have an access to erased values?