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 <[email protected]> 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ő <[email protected]> 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" <[email protected]> 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 <[email protected]> wrote: >>> >>> > On Thu, Dec 4, 2014 at 12:59 PM, migmit <[email protected]> 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 >>> > [email protected] >>> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> > >>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> [email protected] >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> [email protected] >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > > > _______________________________________________ > Glasgow-haskell-users mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > _______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
