confusing type error

[Evan Laforge]

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 <byorgey at gmail.com> 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ő <gergo at erdi.hu> 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" <eir at cis.upenn.edu> 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 <qdunkan at gmail.com> wrote:
>>>
>>> > On Thu, Dec 4, 2014 at 12:59 PM, migmit <migmit at gmail.com> 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 at haskell.org
>>> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>> >
>>>
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>