Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005797OCamlOCaml typingpublic2012-10-23 17:082013-06-28 17:54
Reporterppedrot 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusfeedbackResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0005797: Warning on abstract generic comparison/equality
DescriptionIt 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.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0008307)
gasche (developer)
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 (reporter)
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 (developer)
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 (developer)
2012-10-23 22:51

> or an object.

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

- Issue History
Date Modified Username Field Change
2012-10-23 17:08 ppedrot New Issue
2012-10-23 17:32 gasche Note Added: 0008307
2012-10-23 17:59 ppedrot Note Added: 0008309
2012-10-23 18:13 gasche Note Added: 0008310
2012-10-23 22:51 frisch Note Added: 0008311
2013-06-28 17:54 doligez Status new => feedback


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker