Make >, >=, <, <= operate only on Ints

[lpil]

Order operators current behaviour can be confusing as the automatic ordering may not align with user expectations:

enum Order =
  | Gt
  | Eq
  | Lt

Gt > Lt  // => False

Restrict them to Ints only, and introduce >. etc that operate on Floats.

[MainShayne233]

The ability to compare all types in Elixir came up during my company’s last engineering meeting :p

I personally feel that the trade off of being able to accidentally produce incorrect assertions due to a misunderstanding is not worth the limitation this flexibility. I can’t think of a case where comparing values of different types in this way has major advantages over other methods of defining the same control flow or what have you.

[lpil]

To be clear I'm not suggesting a > b be valid, I'm wondering if > should be restricted from a > b to Int > Int so that enums such as the above could not be compared in a fashion that would be unexpected to the user.

In my example above "less than" is greater than "greater than" because atoms are larger if they are alphabetically larger.

[MainShayne233]

What about Elm's approach to comparables, where the comparison operators can only be used on "numbers, characters, strings, lists of comparable things, and tuples of comparable things"?

[lpil]

I don't like that Elm has these type classes but doesn't allow the user to implement new members of the class.

Any language features should be usable and extendable by the users rather than just the language designers. More rules with fewer exceptions :)

[mbuhot]

Could you define a general purpose compare : a -> a -> bool function that will use the beams comparison primitives, and the > operators to be a convenience syntax only for numeric types?

[lpil]

We could do that. It could also return order:Order, which may be a little clearer.

We couldn't have > work only on numeric types because this would require overloading or a type class again. It could work for ints and there be another >. operator for floats.

[tim2CF]

Does this discussion mean that Gleam will have type classes? :)
Because type classes is prerequisite for polymorphism generally and Ord type class is prerequisite for polymorphic >, >=, <, <= functions particularly.

[lpil]

Gleam does not currently have type classes, though may have something similar in future.

Implementations for this kind of polymorphism will have to be explicitly supplied by the programmer (e.g. sort_by) rather than implicitly supplied by the compiler, like in Erlang or OCaml.