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 <simo...@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-boun...@haskell.org] *On Behalf Of > *Christopher > Allen > *Sent:* 03 March 2016 07:55 > *To:* 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/c27c721b92dab0248433 > <https://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.com
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs