Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005087OCamlOCaml generalpublic2010-06-24 00:282013-08-31 12:43
Reporteryallop 
Assigned Tofrisch 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version3.12.0+beta1 or 3.12.0+rc1 
Target VersionFixed in Version 
Summary0005087: First-class modules and polymorphic comparisons make it possible to compare values of different types
DescriptionGiven the following signature,

module type E =
sig
  type a
  val v : a
end

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.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0005571)
frisch (developer)
2010-06-24 09:46

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 *)
(0006223)
frisch (developer)
2011-12-10 19:08

... 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.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker