Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@herbelin
Copy link
Member

This sequence of commit is restoring a minimal effective form of the "beautifier".

  • It adds a target for checking the reparsability of the result of "beautification" (make check-beautify).
  • It fixes a number of parsing bugs, printing bugs or library's fragile notations found while reparsing the result of beautification.

The infrastructure for re-printing documents can be used for various purposes such as:

  • documentation: it was used by Yann in his unfinished new coqdoc;
  • upgrading: by automatically applying translations so that a file works from a version to another;
  • beautification: changing notations globally in a development;
  • correctness: by testing the reversibility of the term and tactic printers;
  • debugging: by providing a printer usable for debugging.

The "fixing" commits are ready to be committed.

One commit is a workaround in the library to remember that a list has to be printed with a separator (where to put this information? it is not in the generic_argument, but since generic, there is no printer rules associated to it). Another commit is a workaround until when to print "constr:" or "ltac:" is stabilized. ltac code. These are temporary commits waiting for a stable solution.

If no objections, my proposal is to commit all the fixes, and when the printing of ltac stabilize, to add the new target for checking the reversibility of printing/parsing and, then, to have it checked by the Jenkins tools.

Note that the current approach does not re-interpret terms before displaying. It only checks the string->constr_expr->string reversibility. A complementary approach would be to check the
string->constr->string reversibility.

herbelin added 30 commits April 17, 2016 16:26
computed when not in debugging mode (especially those printing a
command).
Notation "## c" := (S c) (at level 0, c at level 100).

which break the stratification of precedences. This works for the case
of infix or suffix operators which occur in only one grammar rule,
such as +, *, etc. This solves the "constr" part of rocq-prover#3709, even though
this example is artificial.

The fix is not complete. It puts extra parenthesese even when it is
end of sentence, as in

Notation "# c % d" := (c+d) (at level 3).
Check fun x => # ## x % ## (x * 2).
(* fun x : nat => # ## x % (## x * 2) *)

The fix could be improved by not always using 100 for the printing
level of "## c", but 100 only when not the end of the sentence.

The fix does not solve the general problem with symbols occurring in
more than one rule, as e.g. in:

Notation "# c % d" := (c+d) (at level 1).
Notation "## c" := (S c) (at level 0, c at level 5).
Check fun x => # ## x % 0.
(* Parentheses are necessary only if "0 % 0" is also parsable *)

I don't see in this case what better approach to follow than
restarting the parser to check reversibility of the printing.
computing the arguments which allows to decide which list of implicit
arguments to consider when several such lists are available.
beautification of the standard library.

Currently not intrusive but needs two extra phases of compilation.
with a clause where, nor Notation, nor Fixpoints.

Should be certainly improved at least for Inductive types and
Fixpoints, depending on whether there is a "where" clause for
instance.
calling Pcoq.parse_string, what some plugins such as coretactics, are
doing, thus breaking the beautification of "Declare ML Module").
allows for a simpler re-printing of assert.

Also fixing the precedence for printing "by" clause.
implicit arguments when in beautification mode.
implicit is found whether one writes (sig P) or {x|P x}.
presence of entries starting with a non-terminal such as "b ^2".
exist as a keyword by inserting a space inbetween.
with user-level notations by inserting spaces.
"|]"" because this commit triggers a

Error: Files proofs/proofs.cma(Miscprint)
       and /usr/local/lib/ocaml/compiler-libs/ocamlcommon.cma(Lexer)
       make inconsistent assumptions over interface Lexer

Adding two extra spaces systematically instead.

This reverts commit 72be1f6beafafc3edd30df673fbb6c7e88f8fac7.
herbelin added 16 commits April 17, 2016 16:26
…nstr.

No other changes (long only because of a change of indentation).
…ntry has a

subentry at a higher tactic level than the entry itself.

This is applicable to the parsing of expressions with infix or postfix
operators such as ; or ||.

Could be improved, e.g. so that no parenthesis are put when the
expression is the rightmost one, as in:

  now (tac1;tac2)

where parentheses are not needed but still printed with this patch,
while the patch adds needed parentheses in

  (now tac1);tac2

This would hardly scale to more complex grammars. E.g., if a suffix
expression can extend a leading expression as part of different
grammar entries, as in

  let x := simpl in y ...

I don't see in general how to anticipate the need for parentheses
without restarting the parser to check the reversibility of the
printing.
the remaining issue with the fix to rocq-prover#3709.

However, this does not solve the problem in mind which is that
"intuition idtac; idtac" is printed with extra parentheses into
"intuition (idtac; idtac)".

If one change the level of printing of TacArg of Tacexp from latom to
inherited, this breaks elsewhere, with "let x := (simpl) in idtac"
printed "let x := simpl in idtac".
side of Ltac's "let ... in ..." or "match ... with ... => ... end".

Example:

Ltac f x := let x := 0 in constr:(S x).
Print Ltac f.

has a missing "constr:".

Note: for generic arguments: "ltac:" is always used, even if a constr, etc.
arguments of vernac extensions, so that in list with a separator, the
separator is printed.
@maximedenes
Copy link
Member

I haven't fully read the code yet, but this PR seems to be doing several orthogonal things, for instance thunking the STM debug messages.

@mattam82
Copy link
Member

We agreed to merge this in 8.6, and I'd really like to see it there. From my cursory look, it has a lot of fixes, the orthogonal change to stm debugging has been commited separately. @herbelin, do you think you'll have time to make it mergeable by friday or need more time? I guess the configure options can be done at a later time.

@ejgallego ejgallego mentioned this pull request Jun 18, 2016
@maximedenes
Copy link
Member

I just saw that the "fixes" in the library are adding useless parentheses like Variable (n : nat). Can we avoid it? Also, I'd like to review this PR more carefully, since it touches many things.

- intros [H| H].
* subst; exists 0; simpl; auto with arith.
* destruct (IH H) as (n & Hn & Hn').
* destruct (IH H) as (n, (Hn, Hn')).
Copy link
Member

Choose a reason for hiding this comment

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

Hum, this is fishy. The whole point of & is to avoid nesting parentheses.

@gares
Copy link
Member

gares commented Jun 20, 2016

I've mainly looked at the "fixed" .v files. I'm not sure it is a good idea to adjust the indentation of lines. Why a user would like that to happen? Also putting let-in on the same line if they fit. If the user breaks the line, such line should stay short.

@herbelin
Copy link
Member Author

herbelin commented Jun 20, 2016

The file "List.v" has nothing to do with a "fixed" .v file (it is part of a not-intended-to-be-merged temporary hack so that the reparsing of beautified files worked until PMP's work on ltac printers is stable, as explained in the PR initial message).

Incidentally, this file shows how the "beautifier" was printing at the time I committed this temporary hack, and it looks like it is starting to inflame passions!

There is evidently some large space of design in deciding what is an optimal "canonical" way of re-printing things. Having parentheses when there is a single declaration in Variable is such a case. Using prioritary ( ... & ... ) or ( ... , ... ), or [ ... | ... ] in intropatterns is such another choice.Indentation of constr expressions is such another issue. These are standard design issues in deciding what is a "good" way to print things. So, beyond passions, how to proceed?

PS: Maxime, don't loose your time in looking at the commits not intended to be committed. If you are interested, you'd better look at those intended to be committed and which I actually (mostly) committed last Thursday! More generally, if you have time to devote to the "beautifier", we can talk of the (numerous) different issues at some time next time we meet (and similarly for Enrico).

@gares
Copy link
Member

gares commented Jun 20, 2016

Ah ok, I thought this PR was in the to-be-merged pipeline. Best,

@gares gares closed this Jun 20, 2016
@herbelin
Copy link
Member Author

Nevertheless, the "beautifier" is not fully unrelated to various questions around interfaces or coqdoc. So, maybe some specialized working group should be organized one of these days on this kind of issues, if one of you, Maxime or Enrico, have the energy to do so.

@herbelin
Copy link
Member Author

PS: Still be to be merged is the "beautifying" testing target. But, as said, having the beautifier "released" requires some further stabilization of the printers, which is unclear whether it can be done in 8.6 or 8.7. So, I see it as a process working independently of the release cycle constraints.

@herbelin
Copy link
Member Author

Continued in #367.

jfehrle pushed a commit to jfehrle/coq that referenced this pull request Dec 19, 2022
158: Provide CPS versions of `abstract_from_[…]`. r=Janno a=Janno

Also inverts the order of definitions by starting with
`abstract_from_term` and deriving `abstract_from_sort` from that.

Co-authored-by: Jan-Oliver Kaiser <[email protected]>
proux01 pushed a commit to proux01/rocq that referenced this pull request Sep 10, 2024
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.

4 participants