subject:"RE\: Specialized type hints"

RE: Specialized type hints

2016-03-07 Thread Simon Peyton Jones

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:e...@cis.upenn.edu]
Sent: 07 March 2016 05:00
To: Simon Peyton Jones <simo...@microsoft.com>
Cc: Christopher Allen <c...@bitemyapp.com>; 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 
<simo...@microsoft.com<mailto:simo...@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:c...@bitemyapp.com<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fbitemyapp.com=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c6b9bd6971ab84198591108d346455a33%7c72f988bf86f141af91ab2d7cd011db47%7c1=Z16BZJdPbEVIqcEIcgF7jebu4vpu5xsuFOsjwNos2wc%3d>]
Sent: 04 March 2016 16:24
To: Simon Peyton Jones <simo...@microsoft.com<mailto:simo...@microsoft.com>>
Cc: ghc-devs@haskell.org<mailto: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 
<simo...@microsoft.com<mailto: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<mailto:ghc-devs-boun...@haskell.org>] On 
Behalf Of Christopher Allen
Sent: 03 March 2016 07:55
To: ghc-devs@haskell.org<mailto: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=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c64d227da349847f85fe308d343391dbb%7c72f988bf86f141af91ab2d7cd011db47%7c1=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<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhaskellbook.com=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c757f72d364664cd81b8508d344497063%7c72f988bf86f141af91ab2d7cd011db47%7c1=EaRmV%2bS3%2f1vgr6klNmr0gM89ofO7CP2%2b7h12bJ%2bJwi8%3d>
___
ghc-devs mailing list
ghc-devs@haskell.org<mailto:ghc-devs@haskell.

Re: Specialized type hints

2016-03-06 Thread Richard Eisenberg

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 <simo...@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:c...@bitemyapp.com] 
> Sent: 04 March 2016 16:24
> To: Simon Peyton Jones <simo...@microsoft.com>
> 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 <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 
> 
>  
> 
> 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

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Specialized type hints

2016-03-04 Thread Simon Peyton Jones

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:c...@bitemyapp.com]
Sent: 04 March 2016 16:24
To: Simon Peyton Jones <simo...@microsoft.com>
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 
<simo...@microsoft.com<mailto: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<mailto:ghc-devs-boun...@haskell.org>] On 
Behalf Of Christopher Allen
Sent: 03 March 2016 07:55
To: ghc-devs@haskell.org<mailto: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=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c64d227da349847f85fe308d343391dbb%7c72f988bf86f141af91ab2d7cd011db47%7c1=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<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhaskellbook.com=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c757f72d364664cd81b8508d344497063%7c72f988bf86f141af91ab2d7cd011db47%7c1=EaRmV%2bS3%2f1vgr6klNmr0gM89ofO7CP2%2b7h12bJ%2bJwi8%3d>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Specialized type hints

2016-03-04 Thread Christopher Allen

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

RE: Specialized type hints

2016-03-04 Thread Simon Peyton Jones

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

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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Specialized type hints

2016-03-03 Thread Brandon Allbery

On Thu, Mar 3, 2016 at 11:58 AM, Eric Seidel  wrote:

> On Wed, Mar 2, 2016, at 23:54, Christopher Allen wrote:
> > 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
>
>
>
> Wow, this is a pretty nasty error message. In particular because it
> relies on the overloaded nature of integer literals.

We actually had another such situation come up in #haskell yesterday, btw.
Someone confused type constructors and data constructors, and the error
message assumed they wanted DataKinds and type level programming. This is
kinda bad for newcomers.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Specialized type hints

2016-03-03 Thread Eric Seidel

On Wed, Mar 2, 2016, at 23:54, Christopher Allen wrote:
> 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

Wow, this is a pretty nasty error message. In particular because it
relies on the overloaded nature of integer literals. Compare

ghci> negate * 10
:2:1:
Non type-variable argument in the constraint: Num (a -> a)
(Use FlexibleContexts to permit this)
When checking that ‘it’ has the inferred type
  it :: forall a. (Num a, Num (a -> a)) => a -> a

with

ghci> negate * (10 :: Int)
:4:11:
Couldn't match expected type ‘a -> a’ with actual type ‘Int’
Relevant bindings include it :: a -> a (bound at :4:1)
In the second argument of ‘(*)’, namely ‘(10 :: Int)’
In the expression: negate * (10 :: Int)
In an equation for ‘it’: it = negate * (10 :: Int)

In the first case (your example), GHC actually finds a valid type for
the expression (assuming FlexibleContexts) because `10` is actually
`fromIntegral 10`, which is overloaded. On the other hand, if you
constrain `10` to be an `Int` there's an immediate unification error,
which is much more helpful.

> 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.

One thing I've noticed other compilers doing (and this might be exactly
what you're hinting at) is provide a sort of provenance of the error, in
the form of warnings and notes. For example, even though using `*` at
`Num (a -> a)` isn't immediately bogus, it is suspicious, so we could
record a note and print it out alongside the error message, should one
arise.

The other thing we could do, which I think would help novices in
particular, is to just allow you to run ill-typed programs in ghci.
Running the program in a debugger gives you so much more information
about what's going on. You did exactly that at the top of your link, but
you had to write out the steps manually, whereas we could have a machine
do it for us! (In fact, I've been working on this lately, albeit for
ocaml programs since we teach ocaml to our undergrads. I think the
results are quite nice http://goto.ucsd.edu:8091)

Eric
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Specialized type hints

Re: Specialized type hints

RE: Specialized type hints

Re: Specialized type hints

RE: Specialized type hints

Re: Specialized type hints

Re: Specialized type hints

7 matches

Site Navigation

Mail list logo

Footer information