Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warning on abstract generic comparison/equality #5797

Open
vicuna opened this issue Oct 23, 2012 · 4 comments

Comments

Projects
None yet
1 participant
@vicuna
Copy link

commented Oct 23, 2012

Original bug ID: 5797
Reporter: @ppedrot
Status: feedback (set by @damiendoligez on 2013-06-28T15:54:18Z)
Resolution: open
Priority: normal
Severity: feature
Category: typing

Bug description

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.

@vicuna

This comment has been minimized.

Copy link
Author

commented Oct 23, 2012

Comment author: @gasche

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?

@vicuna

This comment has been minimized.

Copy link
Author

commented Oct 23, 2012

Comment author: @ppedrot

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.

@vicuna

This comment has been minimized.

Copy link
Author

commented Oct 23, 2012

Comment author: @gasche

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.

@vicuna

This comment has been minimized.

Copy link
Author

commented Oct 23, 2012

Comment author: @alainfrisch

or an object.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.