-
Notifications
You must be signed in to change notification settings - Fork 364
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
Cubical does not ensure EQUIVFUN has left inverse #5661
Comments
I consider the implementations in the .Builtin files part of the trusted codebase, other implementations are not supported. The EQUIVPROOF builtin is there because it is used in the computation of transport, not necessarily to enforce properties of EQUIVFUN. Mostly it would be silly to add tests that make sure that the given implementation of the builtins is equal to the intended one, that would just be repeating the implementation twice. The main reason these are builtins is that their implementation is easier to write as Agda programs than by manipulating the internal representation. I also do not wish to work out a theory where isEquiv is axiomatized, Maybe we need a mechanism so that when |
I suggest that we put the builtin modules in a library called something like |
Is there a list of the Cubical Agda builtins/primitives which one can define in "incorrect" ways? Did your change remove one or more items from this list? |
Off the top of my head, the only bulitins you could mess up are |
If it is possible to mess up anything in such a way that this could lead to an inconsistency or a runtime error, then I think the corresponding binding should only be allowed in non- |
@plt-amy: Fixed issues should be added to the correct milestone, so we can automatically generate the "closed issues" section of the respective CHANGELOG. |
@andreasabel Ah, alright! I'll go through the issues I've closed and see whether any are missing a milestone. Thanks for the shout. |
Version:
Agda version 2.6.3-dbadb16
Description:
When defining the builtins
EQUIV
andEQUIVFUN
, we are forced to prove certain properties about them before we can use them for computing. I believe the point ofEQUIVPROOF
is to ensure thatEQUIVFUN
is surjective. However, there is no check thatEQUIVFUN
is injective, allowing use to defineEQUIV
such that we must provide a right inverse but do not require a left inverse. Using this new definition ofEQUIV
, we can prove that the unit type is equal to the Boolean type via Univalence. Due to only using builtins and primitives, all of this is allowed even with the--safe
option.Code:
The text was updated successfully, but these errors were encountered: