|Anonymous | Login | Signup for a new account||2013-12-06 02:50 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005087||OCaml||OCaml general||public||2010-06-24 00:28||2013-08-31 12:43|
|Product Version||3.12.0+beta1 or 3.12.0+rc1|
|Target Version||Fixed in Version|
|Summary||0005087: First-class modules and polymorphic comparisons make it possible to compare values of different types|
|Description||Given the following signature,|
module type E =
val v : a
the following expression evaluates to 'true':
let m = (module struct type a = int let v = 0 end : E)
and n = (module struct type a = float list let v =  end : E) in
m = n
It seems undesirable for the combination of polymorphic equality and first-class modules to expose representations in this way.
|Tags||No tags attached.|
I agree this is an undesirable property. A clean fix would consist in wrapping packaged modules into a block with a unique id and the same tag as object blocks; we would then have the polymorphic equality coincide with the physical one for packages modules (the physical identity being defined by the packing site), and there would be a clean total ordering as well. The overhead would not be completely negligible for some uses of first-class modules, though.
Another, more lightweight solution, would attach a special tag to the runtime representation of structures (even when not packaged as first class values). This way, packing and unpacking would remain no-ops at runtime. The polymorphic comparison function would simply fail on this special tag (in the same way it fails for functional or external values).
As a side note, exceptions have exactly the same problem:
exception A of int;;
let x = A 0;;
exception A of float list;;
let y = A ;;
x = y;; (* true *)
... and GADTs will give a third way to have the generic comparison function compares values of different types.
I think there is no easy fix, and the problem is not so bad in practice, so I mark this ticket as "won't fix" for now.
|2010-06-24 00:28||yallop||New Issue|
|2010-06-24 09:46||frisch||Note Added: 0005571|
|2011-06-01 23:32||doligez||Status||new => acknowledged|
|2011-12-10 19:08||frisch||Note Added: 0006223|
|2011-12-10 19:08||frisch||Status||acknowledged => resolved|
|2011-12-10 19:08||frisch||Resolution||open => won't fix|
|2011-12-10 19:08||frisch||Assigned To||=> frisch|
|2013-08-31 12:43||xleroy||Status||resolved => closed|
|Copyright © 2000 - 2011 MantisBT Group|