indication that a more general type error improvement sweep would be welcome Absolutely yes. But it depends on someone saying “I want to do that”; and of course on how hard or easy it turns out to be. general UX improvements I would like to undertake. Great! Make Trac tickets proposing changes; debate them with others to form a consensus about what would be good; implement them… that would all be amazing. Simon From: Christopher Allen [mailto:cma@bitemyapp.com] Sent: 04 March 2016 16:24 To: Simon Peyton Jones Cc: ghc-devs@haskell.org Subject: Re: Specialized type hints I was looking for an indication that a more general type error improvement sweep would be welcome. I could pinpoint a particular type error if you liked (such as the one that prompted this email), but there are general UX improvements I would like to undertake. On Fri, Mar 4, 2016 at 4:25 AM, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: Christopher Improving error message is an excellent goal, and one that I have spent more hours on than I care to tell you. If you have a particular one in mind, could you open a Trac ticket with a particular reproducible test case, the error message you get, and the error message you’d like to get. Thanks Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.orgmailto:ghc-devs-bounces@haskell.org] On Behalf Of Christopher Allen Sent: 03 March 2016 07:55 To: ghc-devs@haskell.orgmailto:ghc-devs@haskell.org Subject: Specialized type hints I'd like to see how warm people would be to catching GHC's type error quality up a bit. I did a write-up on a confusion a reader of our book had: https://gist.github.com/bitemyapp/c27c721b92dab0248433https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgist.github.com%2fbitemyapp%2fc27c721b92dab0248433&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c64d227da349847f85fe308d343391dbb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EtjujRikMvoUN%2fBq6RtOrotsPdXdvZggnMU3Cu2BypE%3d This is not new. A lot of people complain about this particular type error in particular when they say GHC has bad type errors. I don't think GHC's type errors are bad, but I do think they could be improved and this particular issue has an unfortunate source to sink distance. I would rather type error improvements not be buried behind a "silly beginners only" flag and that they just be part of improving the UX for everyone. With that proviso, how likely would specialized type error hints and some general error message fix ups be regarded? By specialized I mean, "detect that they tried to find an instance of Num for (-> something something) and suggest that they did the wrong thing, with possible fixes: X Y Z". Ideally before the "hey do you want FlexibleContexts?!" thing fires. I do not think I am capable of doing this, but being able to zoom in, clang style, to the expression where they are (probably accidentally) using a function like a Num or a Num like a function would be pretty valuable so they don't have to guess-n-check parenthesize their code. -- Chris Allen -- Chris Allen Currently working on http://haskellbook.comhttps://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhaskellbook.com&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c757f72d364664cd81b8508d344497063%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EaRmV%2bS3%2f1vgr6klNmr0gM89ofO7CP2%2b7h12bJ%2bJwi8%3d

But (in my defence) it’s pretty cool that error message generation can be left (a) to the end of type checking when all information is available and (b) localised on one module. I can’t tell you how much better it is than it was before! There is _plenty_ of scope for improvement though! Simon From: Richard Eisenberg [mailto:eir@cis.upenn.edu] Sent: 07 March 2016 05:00 To: Simon Peyton Jones Cc: Christopher Allen ; ghc-devs@haskell.org Subject: Re: Specialized type hints I, for one, would greatly welcome someone rewriting much of the TcErrors module. (Almost all type errors are generated in that one module, rather conveniently.) Even better would be to have some written-out theory behind the design of the error-reporting mechanism. What we have now is incredibly ad-hoc and, as frequently reported, rather suboptimal. Richard On Mar 4, 2016, at 11:36 AM, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: indication that a more general type error improvement sweep would be welcome Absolutely yes. But it depends on someone saying “I want to do that”; and of course on how hard or easy it turns out to be. general UX improvements I would like to undertake. Great! Make Trac tickets proposing changes; debate them with others to form a consensus about what would be good; implement them… that would all be amazing. Simon From: Christopher Allen [mailto:cma@bitemyapp.comhttps://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fbitemyapp.com&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c6b9bd6971ab84198591108d346455a33%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Z16BZJdPbEVIqcEIcgF7jebu4vpu5xsuFOsjwNos2wc%3d] Sent: 04 March 2016 16:24 To: Simon Peyton Jones mailto:simonpj@microsoft.com> Cc: ghc-devs@haskell.orgmailto:ghc-devs@haskell.org Subject: Re: Specialized type hints I was looking for an indication that a more general type error improvement sweep would be welcome. I could pinpoint a particular type error if you liked (such as the one that prompted this email), but there are general UX improvements I would like to undertake. On Fri, Mar 4, 2016 at 4:25 AM, Simon Peyton Jones mailto:simonpj@microsoft.com> wrote: Christopher Improving error message is an excellent goal, and one that I have spent more hours on than I care to tell you. If you have a particular one in mind, could you open a Trac ticket with a particular reproducible test case, the error message you get, and the error message you’d like to get. Thanks Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.orgmailto:ghc-devs-bounces@haskell.org] On Behalf Of Christopher Allen Sent: 03 March 2016 07:55 To: ghc-devs@haskell.orgmailto:ghc-devs@haskell.org Subject: Specialized type hints I'd like to see how warm people would be to catching GHC's type error quality up a bit. I did a write-up on a confusion a reader of our book had: https://gist.github.com/bitemyapp/c27c721b92dab0248433https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgist.github.com%2fbitemyapp%2fc27c721b92dab0248433&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c64d227da349847f85fe308d343391dbb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EtjujRikMvoUN%2fBq6RtOrotsPdXdvZggnMU3Cu2BypE%3d This is not new. A lot of people complain about this particular type error in particular when they say GHC has bad type errors. I don't think GHC's type errors are bad, but I do think they could be improved and this particular issue has an unfortunate source to sink distance. I would rather type error improvements not be buried behind a "silly beginners only" flag and that they just be part of improving the UX for everyone. With that proviso, how likely would specialized type error hints and some general error message fix ups be regarded? By specialized I mean, "detect that they tried to find an instance of Num for (-> something something) and suggest that they did the wrong thing, with possible fixes: X Y Z". Ideally before the "hey do you want FlexibleContexts?!" thing fires. I do not think I am capable of doing this, but being able to zoom in, clang style, to the expression where they are (probably accidentally) using a function like a Num or a Num like a function would be pretty valuable so they don't have to guess-n-check parenthesize their code. -- Chris Allen -- Chris Allen Currently working on http://haskellbook.comhttps://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhaskellbook.com&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c757f72d364664cd81b8508d344497063%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EaRmV%2bS3%2f1vgr6klNmr0gM89ofO7CP2%2b7h12bJ%2bJwi8%3d _______________________________________________ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs