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

Discharge on the fly #72

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

herbelin
Copy link
Member

Rendered here.

@herbelin herbelin mentioned this pull request Jul 31, 2023
3 tasks
@jfehrle
Copy link
Member

jfehrle commented Jul 31, 2023

This PR includes a second CEP that you proposed a week or two ago. Is that what you intended?

@herbelin
Copy link
Member Author

Not intended :(.Sorry, removed.

- extending a section content enriches simultaneously and hereditarily all section levels (i.e. `Definition f := t` adds `Top.f` to all section levels, `Top.S.f` to all section levels from level `Top.S`, `Top.S.T.f` to all section levels from level `Top.S.T`, etc.); there are however three kinds of declarations (see below)
- closing a section drops the active copy of the environment/state and makes active the environment/state of the outer section (which itself growed since the fork)

## Definitionally connecting the different copies
Copy link

@CohenCyril CohenCyril Sep 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitional equality is not enough in practice, the various copies must also be identified in the following contexts:

  • in the syntactic phase of rewrite pattern matching
  • in patterns of Hint
  • as canonical keys
  • in Search results

(and I'm not sure how exhaustive is this list)

There are at least the two following ways to address this problem:

  1. Use a notation instead of a definition for aliases in each sections
  2. Call Declare Equivalent Keys all the time and make sure it is taken into account by every relevant part of the system (and document it properly cf [Declare Equivalent Keys] should be documented coq#4551).

Ideally, intermediate definitions should be discarded when exiting the section.

(Optionally, also, in the future, it would be nice if re-entering a named section could provide the same context and the same aliases....)

Copy link
Member Author

@herbelin herbelin Sep 12, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as canonical keys

In my experiences to provide simultaneously the non-discharged and discharged versions of a canonical key, I had several incompatibilities. Studying the reason of these incompatibilities might help to understand if there is a way to make it working, but that does not seem to be straightforward to support (see for instance the failure on mathcomp I got when the discharged versions of a canonical projection are also allowed to be used).

the various copies must also be identified

By identified, I guess you mean eq_constr-equal (alpha-convertible) vs conv-equal. Is it that you think that it would help compatibility? In any case, I struggled in not breaking too much compatibility in coq/coq#17888. I'm a bit pessimistic about the room for manœuver that we have.

(Optionally, also, in the future, it would be nice if re-entering a named section could provide the same context and the same aliases....)

I agree. And it is not impossible to do if we accept to keep the inside of sections in vo files. And, at worst, even if keeping the inner of sections in vo files happens to be too costly in size, we may also recompute dynamically the instances.

[In any case, thanks for your support!]

@CohenCyril
Copy link

Regarding the drop of parameter in Lean4 here is a story:
https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/parameter.20vs.20variable/near/391936460

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants