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