expanding type synonyms in error messages

[Ömer Sinan Ağacan]

Great, thanks Kostiantyn! I'm looking for simple examples that we can
add to GHC testsuite, if I find something I'll update the wiki page
also.

I made some progress on the patch, I think I can hopefully submit
something this weekend for reviews.

2015-06-19 5:16 GMT-04:00 Kostiantyn Rybnikov <k-bx at k-bx.com>:
> Created some initial wiki-page with just one example, will keep it in mind
> to add more as seen.
>
> https://wiki.haskell.org/Expanding_type_synonyms_in_error_messages_proposal
>
> On Fri, Jun 19, 2015 at 10:42 AM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>>
>> On this thread, a representative collection of *reproducible examples*
>> with the actual error message and the desired one, would be tremendously
>> helpful.  Lacking that, it’s hard to know where to begin.   (Creating the
>> examples takes a bit of work, I know.)
>>
>>
>>
>> Start a wiki page!  Stuff in email threads gets lost
>>
>>
>>
>> Simon
>>
>>
>>
>> From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
>> Christopher Allen
>> Sent: 19 June 2015 04:27
>> To: Ömer Sinan Ağacan
>> Cc: ghc-devs
>> Subject: Re: expanding type synonyms in error messages
>>
>>
>>
>> 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
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>