MantisBT - OCaml
View Issue Details
0005797OCamltypingpublic2012-10-23 17:082013-06-28 17:54
ppedrot 
 
normalfeatureN/A
feedbackopen 
 
 
0005797: Warning on abstract generic comparison/equality
It would be very useful to have an activable warning that would occur when using generic equality or comparison over abstract types (other than base types, obviously).

This would permit to improve overall code cleanness.
No tags attached.
Issue History
2012-10-23 17:08ppedrotNew Issue
2012-10-23 17:32gascheNote Added: 0008307
2012-10-23 17:59ppedrotNote Added: 0008309
2012-10-23 18:13gascheNote Added: 0008310
2012-10-23 22:51frischNote Added: 0008311
2013-06-28 17:54doligezStatusnew => feedback
2017-02-23 16:45doligezCategoryOCaml typing => typing

Notes
(0008307)
gasche   
2012-10-23 17:32   
That could be a good idea, but please note that we do not have the static knowledge to do that reliably at compile-time:

- you may use generic comparisons in polymorphic functions that are later instantiated with abstract types (eg. you may use List.assoc on an abstract type, and without a cross-module analysis you can't guess that List.assoc is tainted with that ugly generic equality)

- the generic comparison operators are defined in the standard library through "external ( = ) : ..." definitions, and the compiler can check that a given identifier was added by the environment by such an external. But you may rebind it and the check will fail: (let (=) = (=);;) would probably be enough to defeat the "simple way" to tell if you're looking at a generic comparisons; in the real world this may happen when you parametrize functions over the comparison operation, or functors parametrized over OrderedType that happen to be instantiated with Pervasives.compare


Do you still see value in a static warning with those rather damning limitations? Are you rather looking for a way to instrument your code to detect use of generic comparisons at runtime?
(0008309)
ppedrot   
2012-10-23 17:59   
In a ideal world, we would use typeclasses, but here, even a overly cautious warning may be informative enough. Indeed, it should also complain when used polymorphically, so that the very definition of List.assoc would raise the warning. This is already better than nothing.

The second point is more problematic; a very involved way to fix it would be having not-so-polymorphic quantifications in the type-checker, but I imagine this is far out of reach.
(0008310)
gasche   
2012-10-23 18:13   
This is what SML does with "equality types" double-quoted type variables: ''a. This is a convoluted way to have a very specific qualified type (Eq a) => ... indeed. Waiting for type classes in OCaml!

Another solution some people have used is to compile their code in an environment where (=), (<) and all are rebound to () or 1, so that the compiler forbids them from using it altogether.

I don't think your idea of warning on polymorphic uses is reasonable enough (from a convenience point of view) to actually get implemented by someone. The runtime instrumentation thing, however, may be doable; you can already somehow emulate this on client side by intentionally wrapping the representations of your abstract types in a closure or an object.
(0008311)
frisch   
2012-10-23 22:51   
> or an object.

Objects can be compared/hashed with the generic functions (using their internal ids).