Refactoring the typechecking error handling

[nomeata]

I have a strong urge to refactor the error accumulation; this
recover_with and return_with isn’t really pretty, adds quite useless
noise to the code, and prevents easy use of existing combinators like
List.iter.

So I propose this:

• We collect error messages and warnings in a mutable reference (a list
  or rope) that we just pass down as argument (inside env). This is
  used to collect errors (and warnings), but not for control flow.
  (This simulates the writer monad, without the syntactic overhead).
• The exception no longer carries an argument. This is raised when we
  cannot continue due to an error.
  (This simulates the Maybe monad for computations-that-may-fail.)
• There is a recover_with function that catches the Error, and continues
  with a useful default.
• At the end, we report all errors and warnings in the mutable ref. And
  if there are any errors, we abort compilation.
  See recover_and_report

Now any use of error does not abort futher processing, only
fatal_error does.

The code in pipeline.ml is maybe not the prettiest yet, but lets first
see if this approach actually works inside typing.ml.

[crusso]

Nit: remove the parens around the product unless you want the extra heap indirection this implies in Caml

[crusso]

If this scratches your itch go for it, but it's a shame that some of the type checker functions now need to take an env when before they did not. I would rather abstract all the definitions on a single state parameter and to it via a single, outer common argument but I guess that's just style.

[nomeata]

I would rather abstract all the definitions on a single state parameter and to it via a single, outer common argument but I guess that's just style.

Sorry, I can’t parse it. I wanted to avoid increasing the number of arguments to most functions, so I put it in env. Do you suggest to have a static_env (read-only, only passed down) and dynamic_env (the current one) (with possibly different names, of course)?

Happy to refactor it accordingly; but maybe based on whatever Andreas’ preference is.

[paulyoung]

remove the parens around the product unless you want the extra heap indirection this implies in Caml

@crusso do you know of any resources on this?

[rossberg]

I'm still skeptical overall, but if you want to proceed I'm fine. However, there is a risk here: if you are not very careful, continuing will more often than not either (1) cause many noisy follow-up errors, thereby actually worsening the user experience, or even (2) break invariants of the type checker. I see you already made a lot of errors fatal. I tried to audit all remaining places of non-fatal errors, and a number of them fail on one of these points, so need to be changed. I hope I haven't missed more, can't harm to check again -- as one rule of thumb, any error in an inference-like context should probably be fatal.

I also have some issues with the interface, see comments.

[nomeata]

Ok, all nits should be resolved (assuming I did not overly eagerly mark any as resolved). But in any case I will wait for #88 to be approved and merged first.

[rossberg]

Thanks, looks good, just a few suggestions and nits.

[rossberg]

Thanks!