expanding type synonyms in error messages
Simon Peyton Jones
simonpj at microsoft.com
Fri Jun 19 07:42:35 UTC 2015
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
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
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<mailto: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<mailto: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<mailto: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.
>> On Jun 16, 2015, at 11:20 AM, Ömer Sinan Ağacan <omeragacan at gmail.com<mailto:omeragacan at gmail.com>>
>> > 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<mailto:ghc-devs at haskell.org>
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> ghc-devs mailing list
>> ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Currently working on http://haskellbook.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs