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

Support projection-like definitions #6

Open
flupe opened this issue Jan 24, 2025 · 1 comment
Open

Support projection-like definitions #6

flupe opened this issue Jan 24, 2025 · 1 comment
Labels
bug Something isn't working enhancement New feature or request

Comments

@flupe
Copy link
Collaborator

flupe commented Jan 24, 2025

As always, Agda's projection-like optimization is a pain in the.

Consider the following file:

record Pair (A B : Set) : Set where
  constructor _,_
  field
    fst : A
    snd : B

myfst : {A B : Set}  Pair A B  A
myfst = Pair.fst

Without projection-like, so with the --no-projection-like flag enabled, we get the following typed Lambox environment:

Pair:
  mutual inductive(s):
    Pair
    type variables:  [A, B]
      constructors:
        _,_ (2 arg(s))
          fst : @0
          snd : @1

fst:
  constant declaration:
    type variables: [A, B]
    type: Pair @0 @1 → @0
    body: λ _ → case<Pair{0},0> @0 of λ<[_, _]> @1

snd:
  constant declaration:
    type variables: [A, B]
    type: Pair @0 @1 → @1
    body: λ _ → case<Pair{0},0> @0 of λ<[_, _]> @0

myfst:
  constant declaration:
    type variables: [A, B]
    type: □ → □ → Pair @0 @1 → @0
    body: λ _ _ _ → fst @0

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.

myfst:
  constant declaration:
    type variables: [A, B]
    type: □ → □ → Pair @0 @1 → @0
    body: λ _ → fst @0

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?

@flupe flupe added the enhancement New feature or request label Jan 24, 2025
@flupe
Copy link
Collaborator Author

flupe commented Jan 24, 2025

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.

@flupe flupe added the bug Something isn't working label Jan 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant