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
Comments
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:
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? |
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. |
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. |
Comment author: @alainfrisch
Objects can be compared/hashed with the generic functions (using their internal ids). |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
See also #1642 |
and #6338 |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
x-ref #9926 |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
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.
The text was updated successfully, but these errors were encountered: