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
