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

Locating identifiers in tactics (including ltac2, ssr) #13103

Closed

Conversation

herbelin
Copy link
Member

@herbelin herbelin commented Sep 27, 2020

Kind: "cleanup"

This is part of the project started in #11842.

We use located identifiers in tactics in anticipation of identifying Prim.identref and Prim.ident, with the latter eventually taking a location by default and the former being eventually deprecated.

Tactics intro_move, rename_hyp, instantiate_by_name, fix/cofix, destruct, ... now take a located identifier. This is a compromise in the sense that internal calls to these tactics need to add a dummy loc just to comply to the extended API. On the other side, having the location at hand in error messages is desirable when the call directly comes from the user (for instance, intros H may now hightlight H, though there are still some issues, as indicated in #13100, which make that intro H does not highlight errors on H).

The first commit is shared with #13102 (it does not matter which PR comes first).

The four next commits are about tactics but do not concern interpretation, thus, in some sense, they could have been alternatively in #13100 (for HypLocation) or #13102 (for Derive Inversion or Ltac definitions).

The last six commits (7th to 12th) rely on the support for located identifiers in ARGUMENT EXTEND and TACTIC EXTEND, which is provided by the 6th commit.

In ssrparser, some harmonization could be done, e.g. using Id.t CAst.t in some places rather than Id.t Loc.located (e.g. in SsrHyp). I can do it if there is a will to, or the work can also be shared, if this is what is preferred.

In Ltac2, I did not change the parsing rules so that they possibly pass located identifiers to tactics. I may try to do it, if there is a demand.

@herbelin herbelin added kind: cleanup Code removal, deprecation, refactorings, etc. part: tactics part: parser The parser (also called gramlib, forked from camlp5) labels Sep 27, 2020
@herbelin herbelin added this to the 8.13+beta1 milestone Sep 27, 2020
@herbelin herbelin requested review from a team as code owners September 27, 2020 15:05
@herbelin herbelin force-pushed the master+located-identifiers-tactics branch from ba24eb9 to d26c3f7 Compare September 27, 2020 15:38
@herbelin herbelin requested a review from a team as a code owner September 27, 2020 15:38
@coqbot-app
Copy link
Contributor

coqbot-app bot commented Sep 27, 2020

The job library:ci-fiat_crypto_legacy has failed in allow failure mode
ping @JasonGross

@github-actions github-actions bot added the needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. label Sep 30, 2020
@herbelin herbelin force-pushed the master+located-identifiers-tactics branch from d26c3f7 to 2361efa Compare October 4, 2020 13:25
@coqbot-app coqbot-app bot removed the needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. label Oct 4, 2020
@coqbot-app
Copy link
Contributor

coqbot-app bot commented Oct 4, 2020

The job library:ci-fiat_crypto_legacy has failed in allow failure mode
ping @JasonGross

@herbelin
Copy link
Member Author

The PR removed induction 0 and destruct 0 and this is the cause of failures (or at least the main cause). Some of these uses are actually legitimate. I'm proposing to implement induction and destruct without an argument to mean what the "hackish" induction 0 and destruct 0 did.

@gares
Copy link
Member

gares commented Oct 12, 2020

what the "hackish" induction 0 and destruct 0 did.

What did they do?

@ppedrot
Copy link
Member

ppedrot commented Oct 13, 2020

FTR, I really don't like this PR. It is adding a lot of debugging information in the wrong place, namely the toplevel value of something that is not an AST, thus polluting the runtime with a lot of irrelevant data. Most of the time one does not even want to know about this debug data, especially when it comes from another file, e.g. when declaring toplevel tactics in some general purpose library. Maybe for Ltac1 it's a necessity because there is no clear separation between idents and other similarly shaped data, but I firmly believe that for Ltac2 this should be handled at the level of functions via backtraces, and definitely not at the level of data for such generic purpose types (user-facing ASTs are another matter, though). As such, except if there is a very good argument in favour of this PR I'd prefer a statu quo.

let s, id' = interp_wit wit_ident ist gl id in
s, Id (SsrHyp (loc, id'))
let s, id' = interp_wit wit_identref ist gl (CAst.make ?loc id) in
s, Id (SsrHyp (loc, id'.CAst.v))
Copy link
Member

Choose a reason for hiding this comment

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

I guess this diff hunk supports @ppedrot thesis. Here the loc is already in the AST, the copy in the ident is just getting in the way. It would feel more natural to pass loc to interp_wit frankly.

Copy link
Member Author

Choose a reason for hiding this comment

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

I would say that it is expected that interp_wit takes a loc since it goes from user-facing syntax to "abstract" syntax (the first line of the diff). What is more questionable (and what @ppedrot questions, afaiu) is that interp_wit continues to return the loc (the second line of the diff).

Copy link
Member

Choose a reason for hiding this comment

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

What I meant is that if you don't put the loc in the ident in the fist place, then interp_wit is not going to return it, you can still pass the loc as you pass ist and gl if you need to

@herbelin
Copy link
Member Author

I don't like either to pollute a library part (tactics.ml) with user input data, especially since the library can indeed be called from other files w/o any relation to a user input (this is actually why I avoided to push such locations to tactics.ml in the past). On the other side, it is legitimate to be able to locate errors, so the question of how to do it is open. What would it mean to use "backtraces"? That the loc is attached afterwards by the caller?

For instance, would something like following be acceptable for you: the tactic in tactics.ml raises an exception say (AddLocOfIdent (id,exn)) (or attach id to the info of the exn), and the caller reraises exnwith the loc ofid`?

In any case, I'm ok with the statu quo (the error messages are already designed on the assumption that they do not know the loc and thus repeat the name of the identifier), but I'd really be interested that the underlying issue is not ignored.

The PR has however more than just changing tactics.ml. There is a part which locates the identifiers as AST and this should be kept, up e.g. to have:

val wit_identref : (lident, lident, Id.t) genarg_type

instead of

val wit_identref : lident uniform_genarg_type

Is this OK?

@ppedrot
Copy link
Member

ppedrot commented Oct 13, 2020

Is this OK?

Nah, that's also runtime polluting.

That the loc is attached afterwards by the caller?

More precisely, only attaching such data when inside a script. This could be done by inserting locating wrappers inside the AST in non-strict mode, for instance.

@herbelin
Copy link
Member Author

Nah, that's also runtime polluting.

Do you mean that you have a solution to avoid loc in pretyping.ml and friends?

This could be done by inserting locating wrappers inside the AST in non-strict mode, for instance.

My imagination is unfortunately not big enough to visualize what you have in mind...

@github-actions github-actions bot added the needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. label Oct 15, 2020
@herbelin herbelin force-pushed the master+located-identifiers-tactics branch from 2361efa to 41a1c32 Compare October 15, 2020 23:09
@herbelin herbelin force-pushed the master+located-identifiers-tactics branch from 41a1c32 to 5facd93 Compare October 28, 2020 15:46
@coqbot-app coqbot-app bot removed the needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. label Oct 28, 2020
@coqbot-app
Copy link
Contributor

coqbot-app bot commented Oct 28, 2020

The job library:ci-fiat_crypto_legacy has failed in allow failure mode
ping @JasonGross

@herbelin
Copy link
Member Author

This could be done by inserting locating wrappers inside the AST in non-strict mode, for instance.

If I call e.g. intros x [|y], how this wrapper would know that it is x or y or [|y] or the whole intros x [|y] which has to be highlighted? The information is only known from the code of intros and that would be a complicated protocol to inform the caller of which exact subterm of the arguments is to be highlighted.

@github-actions github-actions bot added the needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. label Nov 5, 2020
@gares gares added the needs: discussion Further discussion is needed. label Nov 16, 2020
@gares gares modified the milestones: 8.13+beta1, 8.14+beta1 Nov 16, 2020
@gares
Copy link
Member

gares commented Nov 16, 2020

My understanding is that this is not ready and some discussion (esp with @ppedrot) has to happen to devise the design

@ppedrot ppedrot modified the milestones: 8.14+rc1, 8.15+rc1 Jun 7, 2021
@coqbot-app
Copy link
Contributor

coqbot-app bot commented Jul 28, 2021

The "needs: rebase" label was set more than 30 days ago. If the PR is not rebased in 30 days, it will be automatically closed.

@coqbot-app coqbot-app bot added the stale This PR will be closed unless it is rebased. label Jul 28, 2021
@coqbot-app
Copy link
Contributor

coqbot-app bot commented Sep 13, 2021

This PR was not rebased after 30 days despite the warning, it is now closed.

@coqbot-app coqbot-app bot closed this Sep 13, 2021
@coqbot-app coqbot-app bot removed this from the 8.15+rc1 milestone Sep 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: cleanup Code removal, deprecation, refactorings, etc. needs: discussion Further discussion is needed. needs: rebase Should be rebased on the latest master to solve conflicts or have a newer CI run. part: parser The parser (also called gramlib, forked from camlp5) part: tactics stale This PR will be closed unless it is rebased.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy