[Haskell-cafe] strange error message

[Semen Trygubenko / Семен Тригубенко]

Hi Casey,

Thanks for your reply.

On Thu, Mar 27, 2014 at 10:07:34PM -0400, Casey McCann wrote:
> On Thu, Mar 27, 2014 at 6:12 PM, Semen Trygubenko / Семен Тригубенко
> <semen at trygub.com> wrote:
> > However, I believe both types should be mentioned, as one is as likely to be wrong as the other.
> > If we are outputting it like that (i.e., one of the two, not both) and care about the amount
> > of output, why are we not outputting the less complex type of the two types involved in a mismatch?
> > r would certainly win that contest.
> >
> > IMHO, I don't think word "expected" is a great word to use here.
> > (length . head) expects to be fed [[a2]] as much as r expects
> > it should be passed into to functions that take Int. ghc should "expect" us
> > to change (length . head) to take Int as much as it "expects" us to fix
> > r to be of type [[a2]].
> 
> I agree that the terms used are less than ideal, but there IS a
> difference between the two types that's worth communicating.
> 
> The cause of this error is because you have a thingie and a place to
> put a thingie and they don't fit together. It's essentially a "square
> peg in a round hole" error, and "Can't fit 'square peg' into 'round
> hole'" is much easier to understand than "Can't match 'square' with
> 'round'.

I agree. Presently the header of the ghc error message reads:
"Can't match 'square' with 'round'.


> Expected shape: round Actual shape: square". But 'round' and
> 'square' aren't interchangeable so they shouldn't be treated as such
> in the message.

There is a symmetry though. Using your analogy, one can try to make the square peg round,
or one can try and make the round hole square. Both are equally valid.

I just wanted to improve the current type error message by ensuring (1) the type is visually
close to the expression it refers to and (2) it is clear in the output
that the peg could be made round OR the hole could be made square for the expression
to typecheck. Presently the header of the type error says: "Couldn't match square with round. I expect square, but in actuality
'it' is round". Expression for 'it' is listed later, and then the context in which 'it' is interacting
with 'something else' that is as likely to be the cause of error as 'it'. IIANM, no type for 'something else'
is given explicitly though, it is left to be deduced, and the expression for 'something else' is not available
in isolation either, only as part of the context.


> While it's easy to learn and interpret what the current message means,
> I think it would be far more helpful for newcomers if it was reported
> more clearly that 1) they have an expression known to have some type
> 'A' 2) which they've used in a context that expects some type 'B' and
> 3) GHC can't unify A and B to get some type C that works for both.
> 
> Perhaps even displaying the surrounding context with the offending
> subexpression replaced with '_'? Sort of mimicking the way the typed
> holes stuff looks, I guess.
> 
> If nothing else though, it would probably help to clarify that it's
> the surrounding code that 'expects' a particular type, rather than
> giving the impression that GHC has an opinion on the matter and
> expects a particular type. GHC just wants them to match, that's all.

I agree. What do people think of the following output then:

test.hs:10:15:
    Couldn't match type `[[a2]]' with `Int'

      (length . head) :: [[a2]] -> Int
                    r :: Int

    In the first argument of `(==)', namely `(length . head) r'
    In the expression: (length . head) r == 0

Does it help to achieve the above?

Many thanks,
S.



-- 
Семен Тригубенко http://trygub.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140328/88f5ef8e/attachment.sig>