-
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
Document the meaning of pattern
without no-eta-equality
#6066
Comments
Perhaps Agda could warn about certain combinations. |
If you explicitly declare record D : Set1 where
eta-equality; pattern; constructor d
field
foo : Set
However, if eta is inferred for the record, you do not get this warning: record D : Set1 where
pattern; constructor d
field
foo : Set
match : D → Set
match (d A) = A
comatch : Set → D
comatch A .D.foo = A I suppose we could throw this warning also in the type-checker, after inferring eta-equality for a record type. |
The warning can be thrown when we turn on eta for a record after positivity checking: agda/src/full/Agda/TypeChecking/Records.hs Lines 464 to 475 in 7183739
agda/src/full/Agda/TypeChecking/Records.hs Lines 477 to 486 in 7183739
If my eyes do not deceive me, these two functions do exactly the same!? They used to be different until e7240e8. |
The warning "useless pattern directive" is now extended to records with inferred eta (was only for declared eta). However, to make it correct, we have to remember whether the record constructor was subject to matching before we inferred eta for the record. (Note: the positivity checker runs at the end of the mutual block.) I wonder whether we should rather advice the user to change `pattern` to `eta-equality` in this case. This would also save us the bookkeeping of record constructor matches.
Ok, there are cases when agda/test/Succeed/Issue2308.agda Lines 13 to 20 in 7183739
This record is classified by Agda as non-recursive. So we have to keep track of whether pattern has been put to use.
|
I am in the process (#6154) of making Agda warn of a redundant @JasonGross @nad @jespercockx @gallais @UlfNorell : Would you want Agda to recommend to replace |
I think that the user should declare whether η-equality should hold or not (via the absence or presence of a keyword), I don't think this property should be inferred by Agda. |
"Inferred" is perhaps a strong word here, but I would be fine with there being a simple syntactic rule for when a record has eta-equality. For example, a record has eta-equality unless it has any of the keywords |
The new implementation separates the query whether an update is necessary from the update. This has to access the signature twice, but skips the update if not needed---rather performing the identity update which produces some garbage that needs to be collected.
@nad and @jespercockx : Thanks for your opinions. I agree that it would be clearer if eta was not inferred, but declared. I second Jesper's proposal, with some modification:
The ETA pragma was kept to allow unsafe eta equality without warning (unless |
The new implementation separates the query whether an update is necessary from the update. This has to access the signature twice, but skips the update if not needed---rather performing the identity update which produces some garbage that needs to be collected.
I don't think we should treat things as unsafe only because the type-checker might fail to terminate. |
If I understand Anton @csetzer correctly, eta for coinductive records also breaks subject reduction: https://www.cs.swan.ac.uk/~csetzer/articles/CMCS2018/bergerSetzerProceedingsCMCS18.pdf |
pattern
without no-eta-equality
shoud be documentedpattern
without no-eta-equality
The documentation at https://agda.readthedocs.io/en/v2.6.2.2/language/record-types.html?highlight=pattern#recursive-records says:
As far as I can tell, the documentation does not specify what
pattern
does when either (or both) of the directivesinductive
,no-eta-equality
are absent, despite the fact that Agda accepts it. I expect this is a no-op (is it?), but I think in any case the behavior should be documented.The text was updated successfully, but these errors were encountered: