expanding type synonyms in error messages

[Christopher Allen]

Just to add my own +1, having this when working with streaming libraries
(I've needed it less with lens, oddly) would be a tremendous help for
people learning them I think. I think I've run into the same thing as
Kostiantyn in the past.

On Thu, Jun 18, 2015 at 9:42 PM, Ömer Sinan Ağacan <omeragacan at gmail.com>
wrote:

> It's good to see that I'm not the only one who wants this. I'm doing
> some GHC hacking nowadays and I'll give it a try.
>
> 2015-06-18 4:41 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
> > 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
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Chris Allen
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150618/7a2637f1/attachment.html>