
Created a patch for reviews/feedbacks: https://phabricator.haskell.org/D1016
2015-06-26 12:40 GMT-04:00 Ömer Sinan Ağacan
Update: I have a patch, it's not quite ready for reviews, but I'm now getting this error message:
Main.hs:17:26: error: Couldn't match type ‘[Char]’ with ‘()’ Expected type: Proxy () String () X IO () (aka. Proxy () [Char] () X IO ()) Actual type: Consumer String IO String (aka. Proxy () [Char] () X IO [Char]) In the second argument of ‘(>->)’, namely ‘doubleUp’ In the second argument of ‘($)’, namely ‘loop >-> doubleUp’ cabal: Error: some packages failed to install: ghc-ty-patch-0.1.0.0 failed during the building phase. The exception was: ExitFailure 1
I'll tidy the code a bit, add a command line flag etc. and submit for reviews.
2015-06-19 10:13 GMT-04:00 Kostiantyn Rybnikov
: Great, thanks for doing this! I'm afraid even if you succeed with patch we would still need more "real-world examples" that show the need for this feature, and I think this is separate from GHC tests, as they don't need to be realistic, but of course please continue and hopefully more examples will come.
19 черв. 2015 16:19 "Ömer Sinan Ağacan"
пише: Done: https://ghc.haskell.org/trac/ghc/ticket/10547
2015-06-19 9:12 GMT-04:00 Richard Eisenberg
: 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
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
: 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
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@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 > > 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 : >> I wanted to add that synonym expansion would be especially helpful >> in >> error-messages like: >> >> Expected type: >> Actual type: >> >> 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" пише: >> >>> 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 >>> >>> 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): >>>> Actual type: <type2> >>>> (without synonyms): >>>> >>>> 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