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 <k...@k-bx.com>: > 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" <omeraga...@gmail.com> пише: > >> 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