Can you (or anyone) point me to the files where this `comparable` logic is implemented in elm compiler? I'll try my hand at least making Bool and Record types Comparable. Or maybe implement comparable Enumerated Type in elm which behaves mostly like custom Union Type.

Even if you find the place in the `elmc` code base, fix it and make a PR: it will not be accepted. This is the walled garden aspect of Elm.

Either you accept the walls or you go with PureScript (which could be described as "Elm without the walls"; but then there is a lot more to learn and a whole plethora of frameworks where Elm has the one-to-rule-m-all-FW baked in).

Or create a fork of Elm, which I would support. I'm very happy using Elm for work over the past 3 years, but it's too limiting for advanced usage.

Maybe a good elm-to-purescript transpiler, that couples with the framework this post links to, is all we need :)

I think if someone implements this thing without breaking backward compatibility, then it will be valuable even as a fork of the original elm compiler. I think the License allows this.

Also, Evan has not closed this issue since 2015. Most probably it is about "too much work to get it right" rather than "I'm not convinced that we need it".

I think type classes is how one would want to fix this. Haskell and PureScript have 'm. But them come with a lot, A LOT, of work. Especially to get the std lib to use them!

With comparability you can use the operators (<,>,<=,>=,==,/=,etc.) on various types. This is not how Elm usually works. I.e. the `map` function is different for `List.map`, `Dict.map`, `Maybe.map`, etc.

In Haskell and PS you have type classes. Some types can be mapped, some can be compared, etc. Then the type class defines what functions should be implemented for such type in order to be part of the type class.

You think it's a small change, but it is pretty much what sets Elm and PS apart. Errors can also get a lot more complex with code that leans heavily on type classes.

It simply won't be merged.