expanding type synonyms in error messages
Ömer Sinan Ağacan
omeragacan at gmail.com
Fri Jun 26 20:17:04 UTC 2015
Created a patch for reviews/feedbacks: https://phabricator.haskell.org/D1016
2015-06-26 12:40 GMT-04:00 Ömer Sinan Ağacan <omeragacan at gmail.com>:
> 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-bx at 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" <omeragacan at gmail.com> пише:
>>
>>> Done: https://ghc.haskell.org/trac/ghc/ticket/10547
>>>
>>> 2015-06-19 9:12 GMT-04:00 Richard Eisenberg <eir at 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 <omeragacan at 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-bx at 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
>>> >>> <simonpj at 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-bounces at 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
>>> >>>> <omeragacan at 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-bx at 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" <eir at 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
>>> >>>>>> <omeragacan at 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 at haskell.org
>>> >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> >>>>>>
>>> >>>>>> _______________________________________________
>>> >>>>>> ghc-devs mailing list
>>> >>>>>> ghc-devs at haskell.org
>>> >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> >>>> _______________________________________________
>>> >>>> ghc-devs mailing list
>>> >>>> ghc-devs at 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 at haskell.org
>>> >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> >>>>
>>> >>>
>>> >> _______________________________________________
>>> >> ghc-devs mailing list
>>> >> ghc-devs at haskell.org
>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> >>
>>> >
More information about the ghc-devs
mailing list