Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Too-general type annotations typecheck on compappend-consuming functions #1422

Closed
alex-lew opened this issue Jun 22, 2016 · 2 comments
Closed

Comments

@alex-lew
Copy link

alex-lew commented Jun 22, 2016

Hi all! Found this today and I thought it could be added to #1373 as another constrained-type-variable-related bug.

The following type annotations should not type-check, but they do:

f : comparable -> Bool
f x = (x ++ x) < x

g : appendable -> Bool
g x = (x ++ x) < x

In the REPL, importing these from a module will lead to weird results (should I report this in elm-repl too?):

> f
<function> : a -> Bool
> g
<function> : a -> Bool
> f 0
TypeError: Cannot read property 'ctor' of undefined

In a compiled module, Elm will not allow you to call f or g on non-compappend arguments, but the error messages can be strange. For example, try pasting this into try-elm:

import Html exposing (text)

f : appendable -> Bool
f xs = xs ++ xs < xs

g = f [text "Hello"]

(It's worth noting as well that trying to annotate f with compappend -> Bool doesn't work, because the compiler does not accept compappend as a constrained type variable within a type annotation. This also leads to a somewhat confusing compiler error, because the compiler suggests you replace your type annotation with compappend -> Bool -- what it already is.)

Hope this is helpful. Thanks for all your work, compiler team!

Edit to add (thanks, process-bot!): I'm using Elm 0.17.0 on Mac OS X El Capitan. try-elm running in Safari

@process-bot
Copy link

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

evancz added a commit that referenced this issue May 11, 2017
The new combineRigidSupers function makes sure that the rigid variable
always wins and that the rigid variable is a subset of the flex
variable.

There was also a bug in unifyRigid where the rigid variable would not
win! The flex one would win. This accounted for some fraction of the
bugs as well.

I also try to avoid allocating new rigid content in unifyRigid to maybe
make things a bit faster.

Fixes #1268
Fixes #1270
Fixes #1281
Fixes #1316
Fixes #1422
Fixes #1581
@evancz
Copy link
Member

evancz commented Jul 14, 2017

With your first comparable example, the error with the latest build is:

-- TYPE MISMATCH ----------------------------------------------

The left argument of (<) is causing a type mismatch.

135| g x = (x ++ x) < x
            ^^^^^^
(<) is expecting the left argument to be a:

    comparable

But the left argument is:

    appendable

Hint: Your type annotation uses type variable `appendable` which means any type
of value can flow through. Your code is saying it CANNOT be anything though!
Maybe change your type annotation to be more specific? Maybe the code has a
problem? More at:
<https://github.com/elm-lang/elm-compiler/blob/0.19.0/hints/type-annotations.md>

With the appendable example, this is the error:

- TYPE MISMATCH ------------------------------------------

The left argument of (<) is causing a type mismatch.

132| f xs = xs ++ xs < xs
            ^^^^^^^^
(<) is expecting the left argument to be a:

    comparable

But the left argument is:

    appendable

Hint: Your type annotation uses type variable `appendable` which means any type
of value can flow through. Your code is saying it CANNOT be anything though!
Maybe change your type annotation to be more specific? Maybe the code has a
problem? More at:
<https://github.com/elm-lang/elm-compiler/blob/0.19.0/hints/type-annotations.md>

The hints are messed up right now, so I am working on fixing those at the moment!

Thanks for the report!

@evancz evancz closed this as completed Jul 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants