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

number is not comparable #1581

Closed
zwilias opened this issue Apr 2, 2017 · 6 comments
Closed

number is not comparable #1581

zwilias opened this issue Apr 2, 2017 · 6 comments

Comments

@zwilias
Copy link
Member

zwilias commented Apr 2, 2017

Fails

five : number
five =
    5

isSmallerThanFive : number -> Bool
isSmallerThanFive number =
    number < five

results in

-- TYPE MISMATCH ------------------------------------------ src/Basics/Extra.elm

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

49|     number < five
        ^^^^^^
(<) is expecting the left argument to be a:

    comparable

But the left argument is:

    number

Hint: Only ints, floats, chars, strings, lists, and tuples are comparable.

Alternatives that do work:

Flipping the args

five : number
five =
    5

isSmallerThanFive : number -> Bool
isSmallerThanFive number =
    five > number

Doing something with the arg first

five : number
five =
    5


isSmallerThanFive : number -> Bool
isSmallerThanFive number =
    (number + 0) < five

Inlining the other number (?)

isSmallerThanFive : number -> Bool
isSmallerThanFive number =
    let
        five : number
        five =
            5
    in
        number < five
@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.

@jvoigtlaender
Copy link
Contributor

Isn't this a duplicate of #1281, which is already recorded in #1373?

@zwilias
Copy link
Member Author

zwilias commented Apr 2, 2017

You're correct. Sorry for the dupe!

@zwilias zwilias closed this as completed Apr 2, 2017
@evancz evancz mentioned this issue Apr 3, 2017
4 tasks
@evancz
Copy link
Member

evancz commented Apr 3, 2017

No need to be sorry @zwilias! As I outline in this thread, I think "duplicate" issues are valuable and very underrated in open source.

Your SSCCE looks clearer to me than the ones referenced by @jvoigtlaender, and I added it to the meta issue! Thank you!

@jvoigtlaender, in the future, can you just note for me that it belongs in the meta issue? In many of your posts like this, I get the sense that it feels a bit confrontational for the OP. No need for that, especially because I prefer "duplicates" with more examples over comments on existing issues!

@jvoigtlaender
Copy link
Contributor

No passive aggression from my side.

@zwilias
Copy link
Member Author

zwilias commented Apr 3, 2017

No passive agression or confrontation experienced on this side, I understand @jvoigtlaender is just triaging and happens to have an almost academical knowledge of open issues. Since dupes are preferred over comments, it makes sense to at least ensure they're cross-referenced.

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants