Hi, My two cents: What is the type of head? What is the type of length? What is the type of length.head? What is the type of r? Best Ivan On 27 March 2014 02:36, Semen Trygubenko / Семен Тригубенко < semen@trygub.com> wrote:

Dear Haskell-Cafe,

Every now and then I get error messages when compiling Haskell code :). Sometimes of the sort:

test.hs:10:15: Couldn't match type `[[a2]]' with `Int' Expected type: Int -> Int Actual type: [[a2]] -> Int The function `length . head' is applied to one argument, but its type `[[a2]] -> Int' has only one In the first argument of `(==)', namely `(length . head) r' In the expression: (length . head) r == 0

Is the middle part of the error message

(The function `length . head' is applied to one argument, but its type `[[a2]] -> Int' has only one)

expected to be confusing like that sometimes?

The line in question, FWIW, is

Right r -> if (length . head) r == 0

It appears as one of the two entries in a case statement, pattern matching on Right constructor.

Many thanks, S.

-- Семен Тригубенко http://trygub.com

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Could you create a code snippet that reproduces the error? Erik On Thu, Mar 27, 2014 at 1:09 PM, Semen Trygubenko / Семен Тригубенко wrote:

Hi Ivan,

On Thu, Mar 27, 2014 at 11:28:33AM +0000, Ivan Perez wrote:

...

What is the type of head? What is the type of length? What is the type of length.head? What is the type of r?

Prelude> :t head head :: [a] -> a Prelude> :t length length :: [a] -> Int Prelude> :t (length . head) (length . head) :: [[a]] -> Int Prelude>

r is of type Int.

[Apologies — I thought the above is deducable from the error message I've included (below).]

Clearly, this is a type error as Int is passed in where [[a]] is expected. However, my question is relating to the middle bit of the error message, namely:

(The function `length . head' is applied to one argument, but its type `[[a2]] -> Int' has only one)

Many thanks, S.

...

On 27 March 2014 02:36, Semen Trygubenko / Семен Тригубенко < semen@trygub.com> wrote:

...

Dear Haskell-Cafe,

Every now and then I get error messages when compiling Haskell code :). Sometimes of the sort:

test.hs:10:15: Couldn't match type `[[a2]]' with `Int' Expected type: Int -> Int Actual type: [[a2]] -> Int The function `length . head' is applied to one argument, but its type `[[a2]] -> Int' has only one In the first argument of `(==)', namely `(length . head) r' In the expression: (length . head) r == 0

Is the middle part of the error message

(The function `length . head' is applied to one argument, but its type `[[a2]] -> Int' has only one)

expected to be confusing like that sometimes?

The line in question, FWIW, is

Right r -> if (length . head) r == 0

It appears as one of the two entries in a case statement, pattern matching on Right constructor.

Many thanks, S.

-- Семен Тригубенко http://trygub.com

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Семен Тригубенко http://trygub.com

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Thu, Mar 27, 2014 at 03:23:35PM +0300, Yuras Shumovich wrote:

It seems to be already fixed: https://ghc.haskell.org/trac/ghc/changeset/b988dc39a06278acc2373ba9a40ee08da...

Ah! Great — in ghc 7.8. Until then let's ignore the middle statement (indeed I thought it might be a bug) — I've replaced it with "<snip> below: test.hs:10:15: Couldn't match type `[[a2]]' with `Int' Expected type: Int -> Int Actual type: [[a2]] -> Int <snip> In the first argument of `(==)', namely `(length . head) r' In the expression: (length . head) r == 0 (1) Why are we biasing the programmer to expect one thing (the function is wrong) and not the other (r is wrong)? I.e., would the programmer benefit from inclusion of the "alternative view" as well? (2) Is it worth stating the context next to the "expected type" message, so that it is clearer what "[[a2]] -> Int" and "expected type" refer to? E.g., test.hs:10:15: Couldn't match type `[[a2]]' with `Int' Actual type (length . head) :: [[a2]] -> Int Expected type :: Int -> Int OR Actual type r :: Int Expected type :: [[a2]] <snip> In the first argument of `(==)', namely `(length . head) r' In the expression: (length . head) r == 0 Many thanks for your kind hel4p, S.

Thanks, Yuras

On Thu, 2014-03-27 at 13:16 +0100, Erik Hesselink wrote:

...

Could you create a code snippet that reproduces the error?

Erik

On Thu, Mar 27, 2014 at 1:09 PM, Semen Trygubenko / Семен Тригубенко wrote:

...

Hi Ivan,

On Thu, Mar 27, 2014 at 11:28:33AM +0000, Ivan Perez wrote:

...

What is the type of head? What is the type of length? What is the type of length.head? What is the type of r?

Prelude> :t head head :: [a] -> a Prelude> :t length length :: [a] -> Int Prelude> :t (length . head) (length . head) :: [[a]] -> Int Prelude>

r is of type Int.

[Apologies — I thought the above is deducible from the error message I've included (below).]

Clearly, this is a type error as Int is passed in where [[a]] is expected. However, my question is relating to the middle bit of the error message, namely:

(The function `length . head' is applied to one argument, but its type `[[a2]] -> Int' has only one)

Many thanks, S.

...

On 27 March 2014 02:36, Semen Trygubenko / Семен Тригубенко < semen@trygub.com> wrote:

...

Dear Haskell-Cafe,

Every now and then I get error messages when compiling Haskell code :). Sometimes of the sort:

test.hs:10:15: Couldn't match type `[[a2]]' with `Int' Expected type: Int -> Int Actual type: [[a2]] -> Int The function `length . head' is applied to one argument, but its type `[[a2]] -> Int' has only one In the first argument of `(==)', namely `(length . head) r' In the expression: (length . head) r == 0

Is the middle part of the error message

(The function `length . head' is applied to one argument, but its type `[[a2]] -> Int' has only one)

expected to be confusing like that sometimes?

The line in question, FWIW, is

Right r -> if (length . head) r == 0

It appears as one of the two entries in a case statement, pattern matching on Right constructor.

Many thanks, S.

-- Семен Тригубенко http://trygub.com

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Семен Тригубенко http://trygub.com

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Семен Тригубенко http://trygub.com

Hi Kim-Ee, On Fri, Mar 28, 2014 at 01:47:02AM +0700, Kim-Ee Yeoh wrote:

On Thu, Mar 27, 2014 at 9:50 PM, Semen Trygubenko / Семен Тригубенко < semen@trygub.com> wrote:

...

(1) Why are we biasing the programmer to expect one thing (the function is wrong) and not the other (r is wrong)? I.e., would the programmer benefit from inclusion of the "alternative view" as well?

The error message isn't really pointing blame, it's just saying, "Yo, I'm stuck at this stage of the inference algorithm so I'm sending the ball back into your court."

Yet it is using words "actual" and "expected" in the output, which can be taken as a gospel by newbies [ or professionals in an emergency ;) ].

But you do have a point.

Thanks!

That said, after a certain amount of experience with ghc, one learns to quickly scan the errors for key bits.

I agree — all the information is there, it's just hard to see it sometimes. :) E.g., earlier in this thread someone was asking about types of entities involved. Anything that can decrease the amount of staring at the type error is good, IMHO. And this is such a cheap modification — changing the way the type checker output looks!

The 'alternative view' repeats essentially the same info twice and including it doubles the amount of spew-out.

Good point (re amount of spew-out). 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]]. How about this: 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 ? Thank you, S. -- Семен Тригубенко http://trygub.com

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 / Семен Тригубенко 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