-
Notifications
You must be signed in to change notification settings - Fork 345
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
A compiler for Cubical Agda programs where all cubical parts have been marked as erased #4701
Comments
I discussed this with @Saizan. He suggested that, in the absence of glue, we could compile the interval to the unit type, and paths to functions from the unit type. I don't think we should have yet another variant of Agda (with glue marked as erased). However, we could have a simple analysis that keeps track of which expressions use glue in non-erased contexts, and then refuse to compile |
We might have to switch off some optimisations. Currently the propositional equality type is compiled to something like the unit type. |
That should be fine if all the cubical stuff is erased? |
These things are subtle (see #4784), so I don't know. However, I was thinking of the compiler for programs where glue is erased, but perhaps not other cubical things. |
Marking all cubical parts as erased might not be so nice. For instance, the builtins are currently not marked as erased in One question is whether type signatures (which are checked in an erased context) can be ignored. Consider the following example: data D : Set where
c₀ : D
c₁ : D → D
@0 D′ : Set
D′ = D
f : D′ → D′
f c₀ = c₀
f (c₁ y) = y Here we can see that A : Set
A = …
@0 Id : Set → Set
Id x = x
f : Id A → A
f x = x Which identifiers are reachable from |
An alternative to the idea to check which things are reachable from
A contrived example: {-# OPTIONS --cubical #-}
module Propositional-truncation where
open import Agda.Builtin.Cubical.Path
data ∥_∥ (A : Set) : Set where
∣_∣ : A → ∥ A ∥
trivial : ∀ x y → x ≡ y {-# OPTIONS --erased-cubical #-}
module Propositional-truncation.Erased where
@0 open import Agda.Builtin.Cubical.Path
@0 import Propositional-truncation as PT
data ∥_∥ (A : Set) : Set where
∣_∣ : A → ∥ A ∥
@0 trivial : ∀ x y → x ≡ y
@0 ∥∥→∥∥ : {A : Set} → PT.∥ A ∥ → ∥ A ∥
∥∥→∥∥ PT.∣ x ∣ = ∣ x ∣
∥∥→∥∥ (PT.trivial x y i) = trivial (∥∥→∥∥ x) (∥∥→∥∥ y) i If this works, then we could perhaps later allow more features (like paths) in non-erased code. |
Ooh, nice. Propositional truncation is probably the one thing outside core Agda that I'd really like to be able to use. |
I'm trying to make Agda parse erased import statements: open @0 import Agda.Primitive (Here The next step is to ensure that all symbols obtained from such an import statement are actually erased. If the information about whether a symbol is erased or not had been part of the scope, then this would presumably have been easy. Would it make sense to include this information in the scope? I guess another approach would be to copy the module and create wrappers for all definitions, but that sounds unnecessarily expensive. Any thoughts? |
The current module macro code handles this kind of copying, and it would be easy to change the quantity of the copied definitions, but there is one problem: statements like import M as Fresh
open Fresh es I think I can make import M as Fresh
@0 open Fresh However, this is not good enough: the names exposed by the In fact, this is a general problem with the explanation of erased import statements given above: "every symbol brought into scope by such a statement would be erased". This is not sufficient, because such symbols could reduce to code that should be treated as erased. |
Another approach that might work:
|
The last sentence does not make sense to me. The flag should not be coinfective. It should be fine to import modules that use |
I have implemented a first draft of I did not change the import statement syntax. Currently all cubical features are allowed when The next step is to add support for compiling code that uses |
Currently at least the following builtins/primitives are allowed:
Let me guess how these could be compiled:
|
I'm not sure you should forbid the primitives from
and then |
However, I don't know a lot about JS or this backend, so perhaps I made some mistake.
However, I don't know a lot about JS or this backend, so perhaps I made some mistake.
However, I don't know a lot about JS or this backend, so perhaps I made some mistake.
However, I don't know a lot about JS or this backend, so perhaps I made some mistake.
See also #5601. |
Perhaps it is possible to compile Cubical Agda programs where all the cubical parts have been marked as erased.
I brought this up during the current Agda meeting, and someone (@txa?) suggested that it should be possible to do better. If I understood correctly the suggestion was that, in a setting without glue, it should be possible to erase all paths and transports (without marking them as erased). However, it's not obvious to me how this could be done.
For instance, consider the following code:
One might imagine that it would be possible to handle the application of a path to 0 or 1 by returning one of the endpoints, but as can be seen above the endpoints might be erased. A fix might be to add an implicit
@0
annotation to all path arguments and disallow the definition off
, but then we're basically back to my original suggestion.Another question concerns functions from the interval. Can they be treated in the same way as paths?
The text was updated successfully, but these errors were encountered: