josefs
Unify type errors for patterns
As part of the effort of solving #49, #137 touched the error reporting for {var, _, _}. As @zuiderkwast writes, the error for expressions should not be the same as the error for patterns (we can't provide a good error description if they are the same).
What we need to happen:
- Expressions and patterns should have distinguishable error formats
- The error format for patterns should be agreed upon, possibly in the same way as its being done for expressions: one at a time
- The error format for expressions is already being worked on but it might need to be modified to distinguish them from patterns
What about an extra field in the error which indicated whether it comes from an expression or a pattern? Or do you have some alternative design in mind? It'd be good to have a concrete proposal to discuss.
@josefs I'll need to do some investigation to answer but my initial feeling is that it should be okay to do as you suggest. This issue basically served as a reminder.
I want the type for returned errors to be very precise so using a boolean had me scared initially. However, for the expressions which can't be patterns, we can eventually refine the type to only allow for false in those cases.
Stay tuned!
A while ago, I suggested this structure (though perhaps not exactly these atoms): {pattern_type_error, Pattern, ActualType, ExpectedType}, while for expressions keeping the current one {type_error, Expr, ActualType, ExpectedType}. How about that?
Perhaps there are other kinds of pattern type errors too, are there?
