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

"Refuse to construct infinite term" in an innocent-looking code #795

Closed
GoogleCodeExporter opened this issue Aug 8, 2015 · 5 comments
Closed
Assignees
Labels
meta Metavariables, insertion of implicit arguments, etc occurs check Problems with checking that metavariable solutions aren't loopy type: bug Issues and pull requests about actual bugs

Comments

@GoogleCodeExporter
Copy link

GoogleCodeExporter commented Aug 8, 2015

The code:

    module test where

    data Q (A : Set) : Set where

    F : (N : Set  Set)  Set₁
    F N = (A : Set)  N (Q A)  N A

    postulate N : Set  Set
    postulate f : F N
    postulate R : (N : Set  Set)  Set
    postulate funny-term :  N  (f : F N)  R N

    qqq : R N
    qqq = funny-term ? (λ A  f ?)

The error message:

    Refuse to construct infinite term by instantiating _9 to Q (?1 A)
    when checking that the expression f ? has type
    N (?1 (Q A)) → N (?1 A)

The error can be fixed in one of the following ways:

* Change Q to be a postulate instead of a data type
* Fill the first hole with N.
* Fill the second hole with A.

I can't explain why any of those changes fix the error or what the error is,
but it sure looks like a bug to me!

Original issue reported on code.google.com by rot...@gmail.com on 18 Feb 2013 at 3:35

@GoogleCodeExporter GoogleCodeExporter added type: bug Issues and pull requests about actual bugs auto-migrated meta Metavariables, insertion of implicit arguments, etc occurs check Problems with checking that metavariable solutions aren't loopy labels Aug 8, 2015
@GoogleCodeExporter
Copy link
Author

Sorry, the formatting is wrong. The actuall error message ends with "N (?1 (Q 
A)) → N (?1 A)", the further text is mine.

Original comment by rot...@gmail.com on 18 Feb 2013 at 3:36

@GoogleCodeExporter
Copy link
Author

GoogleCodeExporter commented Aug 8, 2015

Here is an analysis of the situation:

Agda first creates a (closed) meta variable

  ?N : Set -> Set

Then it checks

  λ A → f ?   against type F ?N = (A : Set) -> ?N (Q A) -> ?N A

(After what it does now, it still needs to check that

  R ?N  is a subtype of R N

It would be smart if that was done first.)

In context A : Set, continues to check

  f ?  against type  ?N (Q A) -> ?N A

Since the type of f is F N = (A : Set) -> N (Q A) -> N A, the created meta,
dependent on A : Set is

  ?A : Set -> Set

and we are left with checking that the inferred type of f (?A A),

  N (Q (?A A)) -> N (?A A)

is a subtype of

  ?N (Q A) -> ?N A

This yields two equations

  ?N (Q A) = N (Q (?A A))

  ?N A     = N (?A A)

The second one is solved as

  ?N = λ z → N (?A z)

simpliying the remaining equation to

  N (?A (Q A)) = N (Q (?A A))

and further to

  ?A (Q A) = Q (?A A)

The expected solution is, of course, the identity, but it cannot be
found mechanically from this equation.

At this point, another solution is ?A = Q.
In general, any power of Q is a solution.

If Agda postponed here, it would come to the problem

  R ?N  =  R N

simplified to ?N = N and instantiated to

  λ z → N (?A z)  =  N

This would solve ?A to be the identity.

Original comment by andreas....@gmail.com on 18 Feb 2013 at 2:48

  • Changed state: Accepted
  • Added labels: Meta, Priority-High, Type-Defect

@GoogleCodeExporter
Copy link
Author

GoogleCodeExporter commented Aug 8, 2015

Oh! And why does changing Q to be a postulate help then?

Original comment by rot...@gmail.com on 18 Feb 2013 at 3:00

@GoogleCodeExporter
Copy link
Author

Good question! ;-)

If you turn on {-# OPTIONS -v tc.meta:50 #-} and then search in the *Agda 
debug* buffer for "term " you see which equations Agda tries to solve.


Original comment by andreas....@gmail.com on 18 Feb 2013 at 3:43

@GoogleCodeExporter
Copy link
Author

Fixed this issue by turning off the error "Refuse to construct infinite term" 
in favor of leaving metas unsolved.

Original comment by andreas....@gmail.com on 18 Feb 2013 at 3:44

  • Changed state: Fixed
  • Added labels: OccursCheck

@andreasabel andreasabel self-assigned this Feb 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta Metavariables, insertion of implicit arguments, etc occurs check Problems with checking that metavariable solutions aren't loopy type: bug Issues and pull requests about actual bugs
Projects
None yet
Development

No branches or pull requests

2 participants