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

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.

...

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:

...

...

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

2015-06-18 4:41 GMT-04:00 Kostiantyn Rybnikov : preserve 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

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.

...

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:

...

...

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

2015-06-18 4:41 GMT-04:00 Kostiantyn Rybnikov : preserve 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

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

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

...

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 <

simonpj@microsoft.com>

...

wrote:

...

On this thread, a representative collection of *reproducible examples* with the actual error message and the desired one, would be

...

...

...

...

helpful. Lacking that, it’s hard to know where to begin. (Creating

...

...

...

...

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

...

...

...

...

(I've needed it less with lens, oddly) would be a tremendous help for

...

...

...

...

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@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 :

...

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

2015-06-19 9:12 GMT-04:00 Richard Eisenberg : tremendously the libraries people 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 < omeragacan@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): >> 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

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