expanding type synonyms in error messages

Kostiantyn Rybnikov k-bx at k-bx.com
Thu Jun 18 08:41:11 UTC 2015


I wanted to add that synonym expansion would be especially helpful in
error-messages like:

Expected type: <non-expanded, small type, like "Producer a m ()">
Actual type: <your type, like "Proxy a a' b b' m v">

I would be glad if we could have an expansions enabling flag in GHC, and
could consider turning it on by default if it will look good for that.
16 черв. 2015 22:44 "Richard Eisenberg" <eir at cis.upenn.edu> пише:

> 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.
>
> Richard
>
> 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
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150618/724c4ca8/attachment-0001.html>


More information about the ghc-devs mailing list