You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As expected, myfst gest two Box arguments that come from its type arguments A and B, but the rest of the signature refers to the type variables.
However, when the optimization is enabled, Agda detects that it is a projection, and drops the parameters in the function definition, and every time it is used.
So its generated type no longer matches its actual body.
The question is: does it suffice to drop the first arguments of a projection-like function? How does it work with type variables generated from the record it operates on? Does it always operate on a record?
The text was updated successfully, but these errors were encountered:
Another solution would be to eta-expand the body of the definition to account for the dropped parameters. But then, we shouldn't forget to also insert Boxes every time this projection-like function is used.
As always, Agda's projection-like optimization is a pain in the.
Consider the following file:
Without projection-like, so with the
--no-projection-like
flag enabled, we get the following typed Lambox environment:As expected,
myfst
gest twoBox
arguments that come from its type argumentsA
andB
, but the rest of the signature refers to the type variables.However, when the optimization is enabled, Agda detects that it is a projection, and drops the parameters in the function definition, and every time it is used.
So its generated type no longer matches its actual body.
The question is: does it suffice to drop the first arguments of a projection-like function? How does it work with type variables generated from the record it operates on? Does it always operate on a record?
The text was updated successfully, but these errors were encountered: