Done: https://ghc.haskell.org/trac/ghc/ticket/10547
2015-06-19 9:12 GMT-04:00 Richard Eisenberg <e...@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 <omeraga...@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...@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 <simo...@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-boun...@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 <omeraga...@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...@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" <e...@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 <omeraga...@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@haskell.org >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>>>> >>>>>> _______________________________________________ >>>>>> ghc-devs mailing list >>>>>> ghc-devs@haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs@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@haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs