feat(print): prefix each printed object with its `locate' report - #1109
Open
bgregoir wants to merge 1 commit into
Open
feat(print): prefix each printed object with its `locate' report#1109bgregoir wants to merge 1 commit into
bgregoir wants to merge 1 commit into
Conversation
`print' resolves a name to one object and shows its declaration, saying
nothing about which of the homonyms in scope that was. It now prefixes
each object it displays with the report `locate' gives for it -- the name
the object is known under, and the shortest form that still resolves to
it:
print op (+).
(* Int.(+) (shorten name: (+)) *)
abbrev (+) : int -> int -> int = CoreInt.add.
The computation lives in `EcPrinting.locate_path', which both commands
now share, so the two cannot drift apart. `ObjectInfo.pr_ty', `pr_op'
and `pr_ax' take `?locate', and `pr_any' turns it on for those three
categories; the others (theories, modules, procedures, module types) get
no report, as `locate' knows nothing about them.
A name with no namespace prefix says nothing the declaration does not,
and is left out -- the convention the `~long' flag of the declaration
printers already followed, and which the report supersedes.
Names are spelled the way the category at hand spells them, through the
new `?pp_name' of `pp_locate_path': an operator needs its parentheses
back to be valid syntax, so the report reads `Int.(+)', not `Int.+'.
Along the way:
- `locate' on an unknown name printed an empty line. The message was
written to the formatter after the only flush, so it never reached
the buffer `notify' reads.
- `print' on an unknown name now names it, and ends on a blank line
like the successful printers do: "no object `x' in the category
[...]" instead of "no such object in the category [...]".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
print' resolves a name to one object and shows its declaration, saying nothing about which of the homonyms in scope that was. It now prefixes each object it displays with the reportlocate' gives for it -- the name the object is known under, and the shortest form that still resolves to it:The computation lives in
EcPrinting.locate_path', which both commands now share, so the two cannot drift apart.ObjectInfo.pr_ty',pr_op' andpr_ax' take?locate', andpr_any' turns it on for those three categories; the others (theories, modules, procedures, module types) get no report, as `locate' knows nothing about them.A name with no namespace prefix says nothing the declaration does not, and is left out -- the convention the `~long' flag of the declaration printers already followed, and which the report supersedes.
Names are spelled the way the category at hand spells them, through the new
?pp_name' ofpp_locate_path': an operator needs its parentheses back to be valid syntax, so the report readsInt.(+)', notInt.+'.Along the way:
locate' on an unknown name printed an empty line. The message was written to the formatter after the only flush, so it never reached the buffernotify' reads.print' on an unknown name now names it, and ends on a blank line like the successful printers do: "no objectx' in the category [...]" instead of "no such object in the category [...]".