On Thu, Dec 4, 2014 at 12:59 PM, migmit wrote:

It tries to get `m Bool` by applying f1 to three arguments: 0, 0, and 'a'. Now, since `f2` has the type `Int -> Float -> n Bool`, where `n` is of kind `* -> *` (and an instance of `Monad` class, but it's not yet the time to look for instances), we have `f2 0 :: Float -> n Bool` and `f2 0 0 :: n Bool`. Since that is applied to 'a', Haskell deduces that the last type should be something like `Char -> Something` — or, equivalently, `(->) Char Something`. Therefore, it can see that `n` is in fact `(->) Char` and `Something` is `Bool`. Therefore, `f2 0 0 'a' :: Bool`. But it is expecting `m Bool`, not `Bool` — which is exactly what an error message says.

Right, that's what I suspected was happening. The confusion arrises because it guesses that 'm' should be (->), and that deduction then leads to a dead-end. But when it reports the problem, it uses its guessed 'm', rather that backing up to the declared value. But surely always backing up to the declared unspecialized value is no good either, because then you get vague errors. All the compiler knows is that when it simplifies as far as it can, it winds up with a /= b, it doesn't know that I would have been surprised by its path a few steps back. But arity errors are common, and intentionally instantiating a prefix type constructor like 'm a' as (->) is probably much less common. So perhaps there could be a heuristic that treats (->) specially and includes an extra clause in the error if it unified a type variable to (->)? I suspect the "expected n but got n" error is also due to the same thing, it counts arrows on one side but inferred arrows on the other? Or something? In any case, it seems like the two sides are counting inconsistently.

But it says `expected Char -> Bool, got Char -> m Bool', note the `m' type constructor in the second one. So it's not `n' vs. `n'. On Dec 5, 2014 10:50 PM, "Richard Eisenberg" wrote:

The reason I said "That's a bug!" so confidently is because of the "expected n but got n" part. Even if everything else is OK, we need to fix that one bit.

And I tend to agree about using heuristics to report better error messages in the presence of instantiating a type variable with (->). I've been caught and confused by that, too.

Richard

On Dec 4, 2014, at 4:23 PM, Evan Laforge wrote:

...

On Thu, Dec 4, 2014 at 12:59 PM, migmit wrote:

...

It tries to get `m Bool` by applying f1 to three arguments: 0, 0, and 'a'. Now, since `f2` has the type `Int -> Float -> n Bool`, where `n` is of kind `* -> *` (and an instance of `Monad` class, but it's not yet the time to look for instances), we have `f2 0 :: Float -> n Bool` and `f2 0 0 :: n Bool`. Since that is applied to 'a', Haskell deduces that the last type should be something like `Char -> Something` — or, equivalently, `(->) Char Something`. Therefore, it can see that `n` is in fact `(->) Char` and `Something` is `Bool`. Therefore, `f2 0 0 'a' :: Bool`. But it is expecting `m Bool`, not `Bool` — which is exactly what an error message says.

Right, that's what I suspected was happening. The confusion arrises because it guesses that 'm' should be (->), and that deduction then leads to a dead-end. But when it reports the problem, it uses its guessed 'm', rather that backing up to the declared value.

But surely always backing up to the declared unspecialized value is no good either, because then you get vague errors. All the compiler knows is that when it simplifies as far as it can, it winds up with a /= b, it doesn't know that I would have been surprised by its path a few steps back.

But arity errors are common, and intentionally instantiating a prefix type constructor like 'm a' as (->) is probably much less common. So perhaps there could be a heuristic that treats (->) specially and includes an extra clause in the error if it unified a type variable to (->)?

I suspect the "expected n but got n" error is also due to the same thing, it counts arrows on one side but inferred arrows on the other? Or something? In any case, it seems like the two sides are counting inconsistently. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

I was going to ask if I should go ahead and file a bug anyway, but I just noticed commit 09b7943321f89b945d10f8a914f4c2cbf73dff91 seems to fix it. Many thanks to Yuras! On Fri, Dec 5, 2014 at 7:50 AM, Brent Yorgey wrote:

I think Richard is referring to "The function ‘f2’ is applied to three arguments, but its type ‘Int -> Float -> Char -> Bool’ has only three". Note "applied to three ... but ... only three". Here n = three.

-Brent

On Fri, Dec 5, 2014 at 9:55 AM, Dr. ÉRDI Gergő wrote:

...

But it says `expected Char -> Bool, got Char -> m Bool', note the `m' type constructor in the second one. So it's not `n' vs. `n'.

On Dec 5, 2014 10:50 PM, "Richard Eisenberg" wrote:

...

The reason I said "That's a bug!" so confidently is because of the "expected n but got n" part. Even if everything else is OK, we need to fix that one bit.

And I tend to agree about using heuristics to report better error messages in the presence of instantiating a type variable with (->). I've been caught and confused by that, too.

Richard

On Dec 4, 2014, at 4:23 PM, Evan Laforge wrote:

...

On Thu, Dec 4, 2014 at 12:59 PM, migmit wrote:

...

It tries to get `m Bool` by applying f1 to three arguments: 0, 0, and 'a'. Now, since `f2` has the type `Int -> Float -> n Bool`, where `n` is of kind `* -> *` (and an instance of `Monad` class, but it's not yet the time to look for instances), we have `f2 0 :: Float -> n Bool` and `f2 0 0 :: n Bool`. Since that is applied to 'a', Haskell deduces that the last type should be something like `Char -> Something` — or, equivalently, `(->) Char Something`. Therefore, it can see that `n` is in fact `(->) Char` and `Something` is `Bool`. Therefore, `f2 0 0 'a' :: Bool`. But it is expecting `m Bool`, not `Bool` — which is exactly what an error message says.

Right, that's what I suspected was happening. The confusion arrises because it guesses that 'm' should be (->), and that deduction then leads to a dead-end. But when it reports the problem, it uses its guessed 'm', rather that backing up to the declared value.

But surely always backing up to the declared unspecialized value is no good either, because then you get vague errors. All the compiler knows is that when it simplifies as far as it can, it winds up with a /= b, it doesn't know that I would have been surprised by its path a few steps back.

But arity errors are common, and intentionally instantiating a prefix type constructor like 'm a' as (->) is probably much less common. So perhaps there could be a heuristic that treats (->) specially and includes an extra clause in the error if it unified a type variable to (->)?

I suspect the "expected n but got n" error is also due to the same thing, it counts arrows on one side but inferred arrows on the other? Or something? In any case, it seems like the two sides are counting inconsistently. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users