Create a data type and functions for runtime errors

[alexgrejuc]

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:

• adding a data type with all of the error cases (see Error/TypeError.hs)
  • these cases should be based off of what appears in Runtime/Eval.hs
• adding a constructor to Err in Error/Error.hs
• creating an Error smart constructor to assign ids (see Error/Error.hs)
• creating helper functions to report these errors in in the evaluation monad in Runtime/Monad.hs (see Typechecker/Monad.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.

[alexgrejuc]

Three necessary runtime errors are:

• out of bounds access
• exceeding the evaluation limit
• division by zero

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?

[MartinErwig]

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