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
[Errors] polish evaluation errors #6043
[Errors] polish evaluation errors #6043
Changes from 7 commits
fb7095b
ac913dd
3847bae
1fde672
0ac3adc
d3d3d20
0b788fc
0aaf06f
b61398d
5484cd4
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 is just to preserve the old behavior, I'm not really sure why we're using
hardline
in error messages.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.
Will
hardline
be added twice in case ofJust cause
?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.
Yes, but there will be pretty-printer
err
in-between, you can see how it gets rendered at the ~bottom of the diff. Anyways, I'm just preserving the old behavior newlines-wise.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 is the only important part of this PR.
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.
How about
data RuntimeError = RuntimeEvalError | RuntimeTypeError
?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'd like to keep it intentionally separate from the whole types realm, we're talking about something entirely different here.
RuntimeTypeError
suggests that it's something about types butSo let's just introduce new terminology for this thing that doesn't seem to match any typery exactly.
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 get what is happening here, but what I don't understand is why we do all this effort to distinquish between operational vs structural errors at actual script validation, by using
Either (ErrorWithCause structural term) (EvaluationResult a)
.From the user's point of view, validating a script would either EvaluationSuccess (validate) or EvaluationFailure (not validate).
In what way does it matter if the non-validation was caused by operational or structural error?
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.
It's explained in the Haddocks:
Basically, it's an extra level of safety for us.
unsafeToEvaluationResult
is used in quite a lot of places and some tests fail if you remove the distinction between operational and structural errors, in the same way that some tests will start to fail if you get typing wrong, even if operationally nothing changes. Just ensures that any evaluation failures are the expected operational ones, not somebody messing up the test.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.
If it is an artifact of Tests alone, then perhaps EvaluationResult should belong to a testlib.
Because taking into account other Plutus-based languages (Aiken,Plutarch,etc) there may not be a distinction between structural vs operational errors and instead they have just errors?
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.
Maybe. I'm currently removing it from builtins where we have a much more appropriate
BuiltinResult
. I doubt I'm going to get motivated enough to see it through though.Perhaps, but I don't really care, I just want us to have that distinction for the same reasons I want us to have a type checker instead of juggling raw
Data
.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 mean, removing
EvaluationResult
from all non-test code, not replace it withBuiltinResult
in the builtins code -- that ship has sailed.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.
And indeed here you show that it does not matter if the error was operational or structural :P
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.
It matters when
extractEvaluationResult
orunsafeToEvaluationResult
are called and they do get called. I'm not sure if reporting whether the error was operational or structural would add meaningful context or just confuse the reader who may not be familiar with the distinction. I do want us to be familiar with the distinction.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.
Here's how the previous version was rendered:
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.
Seems like
stylish-haskell
conflicts withfourmolu
, I promise I didn't add those spaces manually.