expanding type synonyms in error messages

Richard Eisenberg eir at cis.upenn.edu
Tue Jun 16 19:44:43 UTC 2015

GHC tries hard to preserve type synonyms where possible, but of course, it can't preserve all of them. The general rule it tries to follow is: preserve vanilla type synonyms; expand type families. This is true both in expected types and actual types. 
If you have a case where you believe that GHC could preserve a type synonym in an expected type, submit a bug report. (Note that constraint synonyms are particularly hard to preserve!)

It would be very easy to report both the synonym-preserving form and the expanded form in an error report, at the cost of making error reports even more verbose. You're welcome to submit a feature request, and this would likely make a good first patch to GHC if you want to get your hands dirty. I'd personally prefer the feature to be protected behind a flag (to avoid seeing that `String` expands to `[Char]` everywhere, for example), but others may feel differently here.


On Jun 16, 2015, at 11:20 AM, Ömer Sinan Ağacan <omeragacan at gmail.com> wrote:

> Hi all,
> While working with complex types with lots of arguments etc. errors are
> becoming annoying very fast. For example, GHC prints errors in this way:
>    Expected type: <type without any synonyms>
>      Actual type: <type with synonyms>
> Now I have to expand that synonym in my head to understand the error.
> I was wondering if implementing something like this is possible:
> In type error messages, GHC also prints types that are cleaned from type
> synonyms. Maybe something like this:
>         Expected type: <type1>
>    (without synonyms): <type1, synonyms are expanded>
>           Actual type: <type2>
>    (without synonyms): <type2, synonyms are expanded>
> If this is not always desirable for some reason, we can hide this behavior
> behind a flag.
> What do GHC devs think about this? Is this, in theory, possible to do? How hard
> would it be to implement this?
> Thanks.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

More information about the ghc-devs mailing list