Open alexgrejuc opened 4 years ago
Three necessary runtime errors are:
However, some of the current runtime errors are not necessary, because they are or should be caught by the type checker. For example, we handle cases like A < 1
in the evaluator for the sake of completeness, even though this case never occurs because it does not pass type checking.
Should we add constructors for these unnecessary errors as well? Should we retain the code that handles these cases or should we remove it and create partial functions?
On Oct 24, 2020, at 6:23 PM, Alex Grejuc notifications@github.com wrote:
Some of the current runtime errors are not necessary, because they are or should be caught by the type checker. For example, we handle cases like A < 1 in the evaluator for the sake of completeness, even though this case never occurs because it does not pass type checking.
Should we add constructors for these unnecessary errors as well?
We could one catch-all constructor for such "uncaught" or "unexpected" errors. The error message should include helpful information for fixing the compiler bug and should include a request to the user to report the error to the language developers.
-- Martin
We already have this for type errors; we need a similar functionality for runtime errors so that we can standardize and consolidate error reporting. This can be implemented by:
Err
in Error/Error.hsError
smart constructor to assign ids (see Error/Error.hs)Once this is done, the existing runtime errors that are manually written in Runtime/Eval.hs should be replaced with instances of the helper functions.
We can then use this infrastructure to reclassify, reword, extend or otherwise edit the existing errors, likely with the feedback of instructors and users. That is a separate issue, however.