... | ... | @@ -101,7 +101,7 @@ The implementation in GHC is fairly straight-forward: |
|
|
|
|
|
- We add custom pretty printing (in `TcErrors`) for unsolved constraints of the form `TypeError msg :: Constraint`. The custom pretty printing code examines `msg` and interprets it using the standard pretty printing combinators.
|
|
|
|
|
|
- When interpreting `msg` it is useful to evaluate type level functions that we encounter along the way. This allows the programmer to use type-level functions to construct the `msg`. OTOH, the types within `ShowType` are printed as is, without evaluating function any more than usual. **SLPJ** Here I'm not sure. A good deal of evaluation will happen automatically simply through the usual flattening mechanism. Including in the arugment of `ShowType` unless we take measures to stop it.
|
|
|
- When interpreting `msg` it is useful to evaluate type level functions that we encounter along the way. This allows the programmer to use type-level functions to construct the `msg`. OTOH, the types within `ShowType` are printed as is, without evaluating function any more than usual. **SLPJ** Here I'm not sure. A good deal of evaluation will happen automatically simply through the usual flattening mechanism. Including in the arugment of `ShowType` unless we take measures to stop it. **Iavor:** I think it is OK for GHC to evaluate as much as it wants in the printed types. I added this point because I had to add some extra code to force some additional evaluation in the `msg`, *outside* of ShowType. For example, if the error message is itself computed using a type-level function, we want to make sure that we fully evaluate this function, so that we get to the combinators of the DSL.
|
|
|
|
|
|
- `TypeError msg :: k` where `k` is not constraint is printed simply as `(type error)`. The reason for this is that on occasion such types may appear in other parts of the error message and we don't want to print the error multiple times, or in its ugly DSL form.
|
|
|
|
... | ... | |