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

First-class modules and polymorphic comparisons make it possible to compare values of different types #5087

Closed
vicuna opened this issue Jun 23, 2010 · 2 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented Jun 23, 2010

Original bug ID: 5087
Reporter: @yallop
Assigned to: @alainfrisch
Status: closed (set by @xavierleroy on 2013-08-31T10:43:58Z)
Resolution: won't fix
Priority: normal
Severity: minor
Version: 3.12.0+beta1 or 3.12.0+rc1
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @glondu "Julien Signoles" @hcarty

Bug description

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

@vicuna
Copy link
Author

vicuna commented Jun 24, 2010

Comment author: @alainfrisch

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 *)

@vicuna
Copy link
Author

vicuna commented Dec 10, 2011

Comment author: @alainfrisch

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants