Done: https://ghc.haskell.org/trac/ghc/ticket/10547
2015-06-19 9:12 GMT-04:00 Richard Eisenberg <[email protected]>: > 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 <[email protected]> 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 <[email protected]>: >>> 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 <[email protected]> >>> 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:[email protected]] 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 <[email protected]> >>>> 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 <[email protected]>: >>>>> 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" <[email protected]> пише: >>>>> >>>>>> 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 <[email protected]> >>>>>> 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 >>>>>>> [email protected] >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>>> >>>>>> _______________________________________________ >>>>>> ghc-devs mailing list >>>>>> [email protected] >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> [email protected] >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Chris Allen >>>> >>>> Currently working on http://haskellbook.com >>>> >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> [email protected] >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> >> _______________________________________________ >> ghc-devs mailing list >> [email protected] >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
