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.
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
#3959, #7202: in script mode, handle directive errors #10476
#3959, #7202: in script mode, handle directive errors #10476
Changes from 1 commit
8ac50b2
63d0292
d3956e0
519b6ca
4819e28
01019e5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This logic is not reentrant, in the sense that the error handler remains set after the script has run. I would expect that you reset it to its previous value after running the script. (Doing this with your API is surprisingly tricky; if you exposed a
ref
directly you could useMisc.protect_refs
, or you could exposewith_error_handler
using it internally.)What happens if I use
#use "a.ml";;
from an interactive toplevel, which succeeds correctly, and then I run another directive that fails?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code path isn't hit if you're in an interactive toplevel, I think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, in scripting mode, we never go back to interactive mode. In fact, we are only running the first script given as argument.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: there is something subtly wrong with the fact that directives take a single formatter, on which they only print errors. This is the property that you use in this refactoring, but it does not hold for all directives, which is why your PR needs special treatment of
#help
and#show
. (What is the expected behavior of#show_val fubar;;
in non-interactive mode?)I think that there would be various ways to improve on this:
directive_fun
types to addoppf:Format.formatter -> eppf:Format.formatter ->
, and let Toploop pass the formatters.error_formatter ()
directly. (But this makes it harder to redirect directive output to a completely different place.)I'm not so fond of (3). (2) sounds nice, but it may have unpleasant backward-compatibility implications for utop and down. It may be that the best compromise is to remain "subtly wrong" and not change the interface at all, as this PR is doing, but this is worth a discussion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tend to agree that morally directives should take both an error and output formatters as argument, and the current set of directives accidentally only use one of them.
I would expect the result of
show
to be print onstdout
as part of the script result.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this example,
fubar
is missing from the environment, I wondered if it should be counted as a directive failure or not. (Currently it is not, I guess?)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, it is not. And keeping it that way seems somewhat sensible (if certainly a bit arbitrary): sucesses or failures of
#show
do not alter the state of the script. Or looking from another perspective, a failure to find an identifier is still a valid answer to the user's query "show me some information aboutfubar
".