expanding type synonyms in error messages

[Ömer Sinan Ağacan]

Done: https://ghc.haskell.org/trac/ghc/ticket/10547

2015-06-19 9:12 GMT-04:00 Richard Eisenberg <eir at cis.upenn.edu>:
> Don't forget to make a Feature Request on Trac (https://ghc.haskell.org/trac/ghc/newticket) with a link to the wiki page. Trac is really the only way things like this don't get lost.
>
> Thanks!
>
> Richard
>
>
> On Jun 19, 2015, at 9:07 AM, Ömer Sinan Ağacan <omeragacan at gmail.com> wrote:
>
>> 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
>>>>
>>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>