Repository navigation
Type synonyms in error messages #1821
Description
type Foo = {foo::Int}
bar :: Foo -> _
bar x = x + 1
Is it possible to use Foo instead of { foo :: Int} in error message?
It's much harder to understand the error especially with big records.
Could not match type
{ foo :: Int
}
with type
Int
while trying to match type { foo :: Int
}
with type Int
while checking that type { foo :: Int
}
is at least as general as type Int
while checking that type Int
is at least as general as type { foo :: Int
}
while checking that expression 1
has type { foo :: Int
}
while applying a function ((+) (#dict Semiring _1)) x
of type _1 -> _1
to argument 1
while inferring the type of ((+) x) 1
while checking that expression ((+) x) 1
has type _0
while checking that expression \x ->
((+) x) 1
has type { foo :: Int
}
-> _0
in value declaration bar
where _0 is an unknown type
_1 is an unknown type
Activity
zudov commentedon Jan 19, 2016
While I don't agree that the provided example is easier with collapsed type synonyms (I would prefer to see
{ foo :: Int }in the error message), it would be nice if the compiler could collapse those expanded type names after a configurable amount of levels (e.g. firstnlevels would be shown expanded, and other would remain as they were in code). For instance in halogen type synonyms allow to manage components more-or-less conveniently. But when you start rearranging them error messages can span across multiple screens.From the implementation point of view, if I understand correctly, type synonyms are fully expanded during compilation, so it's probably not that easy to restore the original names.
hdgarrood commentedon Jan 19, 2016
I think it's probably sensible for the compiler to say, "if there is a synonym in scope for this type, then that probably means the human finds the synonym easier to understand, so I should use the synonym". If the synonym were not easier to understand, presumably, it would have no reason to exist? At least, in most cases. My gut feeling is that this reasoning will apply in enough cases for it to be a sensible approach.
GHC does use type synonyms in its error messages, so while it may not be easy, it certainly ought to be possible, right?
garyb commentedon Jan 19, 2016
The information is gone by the time it reaches these kind of errors. Synonyms are fully desugared as we kept running into cases where synonyms were incorrectly handled.
It definitely is possible to retain some use of synonyms for errors/warnings, it's something I intend to revisit in 0.9 perhaps.
garyb commentedon Jan 19, 2016
See #1443 for the kind of problems synonyms can still cause, even despite the earlier desugaring pass we have now 😉
paf31 commentedon Jan 19, 2016
We used to keep synonyms around through type checking, but as @garyb noted, it led to some issues. It could be done better though.
[-]Type name in error messages[/-][+]Type synonyms in error messages[/+]paf31 commentedon Apr 15, 2017
I think this is another issue which will be simplified by the annotations work @garyb is doing, since we can annotate the expanded type during synonym expansion, and then look for it during pretty printing.