# Removing polymorphic compare from Core **URL:** \ **Category:** Ecosystem\ **Created:** [December 2, 2018, 5:16pm UTC](https://discuss.ocaml.org/t/removing-polymorphic-compare-from-core/2994 "2018-12-02T17:16:39Z")\ **Posts on this page:** 1\ **Showing post:** 12
**Author:** ![gasche](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/gasche/32/4_2.png) [@gasche](https://discuss.ocaml.org/u/gasche)\ **Post date:** [December 4, 2018, 9:36pm UTC](https://discuss.ocaml.org/t/removing-polymorphic-compare-from-core/2994/12 "2018-12-04T21:36:26Z")
Yes, this shouldn’t be too hard. A few things to watch for: - Abstract types can make it impossible to know from the typedtree whether a type is comparable. We have a syntax to declare through an abstraction boundary that a type is “immediate” (represented by an integer), but not the corresponding “comparable” or “eqtype” restriction. Either you extend the signature language, or you have to reject certain programs. - `(=)` or `compare` can be passed as argument to a function expecting an instance (`List.sort compare : string list -> string list`), so you have to check the instantiation sites of polymorphic operators, rather than just application sites. - Polymorphic comparison operators can be rebound, in a module or across module boundaries. In theory you should just warn on any operator at the type `forall 'a. 'a -> 'a -> {int,bool}`, they are either silly or non-parametric. In practice I’m not sure that rebinding polymorphic comparisons (rather than specialized instances) is a common practice. Looking at how `[@@immediate]` is computed/checked/used in the compiler codebase could be a good entry point to get an idea of how to do this. --- _[View the full topic](https://discuss.ocaml.org/t/removing-polymorphic-compare-from-core/2994)._