-
Notifications
You must be signed in to change notification settings - Fork 338
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
Singleton check loops on recursive eta record #5823
Labels
eta
η-expansion of metavariables and unification modulo η
records
Record declarations, literals, constructors and updates
singleton-types
Issues related to conversion modulo eta-equality for singleton types
type: bug
Issues and pull requests about actual bugs
Milestone
Comments
Agda loops when trying to check whether
|
andreasabel
added a commit
that referenced
this issue
Mar 10, 2022
…rd types Otherwise we might get into infinite unfolding...
andreasabel
added a commit
that referenced
this issue
Mar 11, 2022
Here is a MWE that makes Agda loop (since Agda 2.5.1.1, when record Empty : Set where
inductive; eta-equality
field out : Empty
test : Empty
test = _ |
andreasabel
added a commit
that referenced
this issue
Mar 22, 2022
…rd types Otherwise we might get into infinite unfolding...
andreasabel
added a commit
that referenced
this issue
Mar 22, 2022
andreasabel
added a commit
that referenced
this issue
Mar 23, 2022
For inductive record types with eta-equality, the check for singleton type (constructing the unique inhabitant) was looping for non-terminating records. As a remedy, the check now keeps a record of already unfolded recursive record types. This alone is too restrictive, because "terminating" record types should always be unfolded (to their field telescope). The Data.Record module from the standard-library relied on this feature in order to construct the record signature automatically by basically just eta-expansion. To keep Data.Record etc working, this commit also adds a termination checker for record types. To this end, a record type record R pars : Set where field f1 : A1 ... fn : An is considered as a list of definitions R pars = A1 ... R pars = An which are subjected to call extraction and termination checking. Record types that fail the termination check are remembered as such, setting recTerminates = Just False in the `Record` `Definition`, but no termination error is reported.
andreasabel
added a commit
that referenced
this issue
Mar 23, 2022
For inductive record types with eta-equality, the check for singleton type (constructing the unique inhabitant) was looping for non-terminating records. As a remedy, the check now keeps a record of already unfolded recursive record types. This alone is too restrictive, because "terminating" record types should always be unfolded (to their field telescope). The Data.Record module from the standard-library relied on this feature in order to construct the record signature automatically by basically just eta-expansion. To keep Data.Record etc working, this commit also adds a termination checker for record types. To this end, a record type record R pars : Set where field f1 : A1 ... fn : An is considered as a list of definitions R pars = A1 ... R pars = An which are subjected to call extraction and termination checking. Record types that fail the termination check are remembered as such, setting recTerminates = Just False in the `Record` `Definition`, but no termination error is reported.
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
eta
η-expansion of metavariables and unification modulo η
records
Record declarations, literals, constructors and updates
singleton-types
Issues related to conversion modulo eta-equality for singleton types
type: bug
Issues and pull requests about actual bugs
The following code loops in Agda 2.6.2.1:
It uses a recursive inductive record (the
Acc
type for well-founded recursion), and tries to prove a property on it by recursing over it.I am not sure if this behaviour is expected (it goes away if
eta-equality
is replaced bypattern
), but the manual seems to suggest that this code should be safe.The text was updated successfully, but these errors were encountered: