The code currently uses withContextM (previously reviseErrorM) in several different ways:
To add a parent message indicating why nested operations happened, e.g., checking args passed to a function.
To direct the user to where to look for more information in the code, e.g., the name and line number of a testcase.
To provide the "real" error message when no alternatives were found, i.e., a failed mergeAnyM or collectFirstM.
Since CompileInfoT applies the context to both warnings and errors, using withContextM for error messages makes nested warnings appear to be errors.
For example, compileWarningM "Warning" <?? "Error!" results in a success with a warning what includes "Error!" as its context.
So, it might make sense to add a second function to CompileErrorM that behaves like reviseErrorM used to before warnings could be nested, e.g., summarizeErrorM.
The code currently uses
withContextM
(previouslyreviseErrorM
) in several different ways:testcase
.mergeAnyM
orcollectFirstM
.Since
CompileInfoT
applies the context to both warnings and errors, usingwithContextM
for error messages makes nested warnings appear to be errors.For example,
compileWarningM "Warning" <?? "Error!"
results in a success with a warning what includes "Error!" as its context.So, it might make sense to add a second function to
CompileErrorM
that behaves likereviseErrorM
used to before warnings could be nested, e.g.,summarizeErrorM
.