Skip to content
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

Agda loops on simple code with a record and a hole #3597

Closed
guillaumebrunerie opened this issue Feb 28, 2019 · 5 comments
Closed

Agda loops on simple code with a record and a hole #3597

guillaumebrunerie opened this issue Feb 28, 2019 · 5 comments
Assignees
Labels
eta η-expansion of metavariables and unification modulo η meta Metavariables, insertion of implicit arguments, etc occurs check Problems with checking that metavariable solutions aren't loopy records Record declarations, literals, constructors and updates type: bug Issues and pull requests about actual bugs
Milestone

Comments

@guillaumebrunerie
Copy link
Member

Agda loops when trying to type-check the simple code below (which should type-check without any issues). It also ends up using all the memory available although this is not progressive, it alternates between moments where memory usage increases quickly and calm periods.

If the field A is taken out of the record (either as a postulate or as a goal), if the argument of eq is replaced by A, or if C is replaced by a postulate, then it works.

open import Agda.Builtin.Equality

record R : Set₁ where
  field
    A : Set
    a : A
    eq : a ≡ a  a ≡ a

C : R
C = {!!}

open R C

test : a ≡ a  a ≡ a
test p = eq p
@guillaumebrunerie
Copy link
Member Author

It loops with versions 2.5.4.1 and 2.5.3 as well.

@guillaumebrunerie guillaumebrunerie added the type: bug Issues and pull requests about actual bugs label Feb 28, 2019
@guillaumebrunerie
Copy link
Member Author

Memory usage does not seem to increase at all with 2.5.3, but it does with 2.5.4.1 and with master at about the same rate (4.4 G after 30 seconds, 8.7 G after one minute, 17.3G after two minutes).

@guillaumebrunerie
Copy link
Member Author

It also works if we add no-eta-equality in R.

@andreasabel andreasabel added eta η-expansion of metavariables and unification modulo η records Record declarations, literals, constructors and updates labels Mar 1, 2019
@andreasabel
Copy link
Member

Seems like we are building a cycle here:

C = _8
_8 = record { A = _15; a = _16; eq = _17 }
_15 = C .A

which blows up when we try to eta expand _16 or type _15.
The metaOccursCheck does not look into the definition C because it is not mutual with test.

@andreasabel andreasabel added the occurs check Problems with checking that metavariable solutions aren't loopy label Mar 2, 2019
andreasabel added a commit that referenced this issue Mar 3, 2019
@jespercockx jespercockx added this to the 2.6.1 milestone Mar 4, 2019
@andreasabel andreasabel self-assigned this Mar 18, 2019
@andreasabel andreasabel modified the milestones: 2.6.1, 2.6.0 Mar 18, 2019
@andreasabel
Copy link
Member

Fixed with Ulf at AIM XXIX: The problem is that a frozen meta is eta-expanded, and the new metas are not frozen. This renders freezing of record metas inefficient in some cases, and the occurs check relies on proper freezing for detecting cycles.
Solved by eta-expanding frozen record metas to records of frozen(!) metas.

@andreasabel andreasabel added the meta Metavariables, insertion of implicit arguments, etc label Mar 18, 2019
andreasabel added a commit that referenced this issue Mar 18, 2019
instead of freezing them immediately after creation as part of the
record value used for eta-expanding a frozen record meta.
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 η meta Metavariables, insertion of implicit arguments, etc occurs check Problems with checking that metavariable solutions aren't loopy records Record declarations, literals, constructors and updates type: bug Issues and pull requests about actual bugs
Projects
None yet
Development

No branches or pull requests

3 participants