expanding type synonyms in error messages

Richard Eisenberg eir at cis.upenn.edu
Fri Jun 19 13:12:34 UTC 2015


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
> 



More information about the ghc-devs mailing list