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

Incorrect names can be generated for generalised variables #4291

Closed
nad opened this issue Dec 16, 2019 · 3 comments · Fixed by #5216
Closed

Incorrect names can be generated for generalised variables #4291

nad opened this issue Dec 16, 2019 · 3 comments · Fixed by #5216
Assignees
Labels
generalize Related to generalisable variables names type: bug Issues and pull requests about actual bugs
Milestone

Comments

@nad
Copy link
Contributor

nad commented Dec 16, 2019

The following code should not be accepted:

open import Agda.Builtin.Equality

variable
  A : Set₁
  x : A

postulate
  f : (B : Set)  B ≡ B  Set

g : f _ x ≡ f _ x
g {B = B} = refl

Agda infers the following type for g:

{B : Set} {x : B ≡ B}  f B x ≡ f B x

The function g should not have an implicit argument called B.

@nad nad added type: bug Issues and pull requests about actual bugs generalize Related to generalisable variables labels Dec 16, 2019
@nad nad added this to the 2.6.2 milestone Dec 16, 2019
@nad
Copy link
Contributor Author

nad commented Sep 14, 2020

Here is another example:

variable
  A : Set
  x : A

postulate
  F : Set  Set
  P : {x : Set}  F x  Set
  p : P x

-- fails : (A : Set) (f : F A) → P f
-- fails A f = p {x = f}

works : (A : Set) (f : F A)  P f
works A f = p {x = _} {x = f}

Agda infers the following type for p:

{x : Set} {x = x₁ : F x}  P x₁

There should only be one implicit argument called x. With the current naming scheme I guess the first argument should be called x.x, or something like that.

@andreasabel
Copy link
Member

We need to distinguish user-written from system-generated names more seriously. In the OP, the name B should be marked as system-generated so that it cannot be referred to in the input.

@UlfNorell UlfNorell self-assigned this Feb 16, 2021
UlfNorell added a commit that referenced this issue Feb 16, 2021
instead of the name suggestion of the meta
UlfNorell added a commit that referenced this issue Feb 16, 2021
@UlfNorell
Copy link
Member

Both names should be x.A.1. PR above fixes this and clarifies the naming scheme in the user manual.

UlfNorell added a commit that referenced this issue Feb 16, 2021
UlfNorell added a commit that referenced this issue Feb 17, 2021
instead of the name suggestion of the meta
UlfNorell added a commit that referenced this issue Feb 17, 2021
UlfNorell added a commit that referenced this issue Feb 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
generalize Related to generalisable variables names type: bug Issues and pull requests about actual bugs
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants