Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006304OCamlOCaml generalpublic2014-01-24 11:382014-07-16 17:34
ReporterJulien Signoles 
Assigned Togarrigue 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version 
Target Version4.03.0+devFixed in Version 
Summary0006304: Explicit interface for a pack, "module type of" and type generativity
DescriptionConsider the following files:
=====
a.mli:
type t = X (* replacing 't' with a non-generative type works fine *)

b.ml:
let x = A.x

pack.mli
module A: module type of A
module B: module type of B
  (* sig val x: A.t end (* this version works fine *) *)
=====

$ ocamlc -c a.mli && ocamlc -c b.ml && ocamlc -c pack.mli && ocamlc -pack -o pack.cmo a.cmi b.cmo
File "_none_", line 1:
Error: The implementation (obtained by packing)
       does not match the interface pack.mli:
       In module B:
       Modules do not match:
         sig val x : A.t end
       is not included in
         sig val x : A.t end
       In module B:
       Values do not match: val x : A.t is not included in val x : A.t

It looks like a bug, in particular because the following version, which provides an explicit file pack.ml equivalent (?) to the generated pack, works fine:
=====
pack.ml:
module A = A
module B = B
====
$ ocamlc -c a.mli && ocamlc -c b.ml && ocamlc -c pack.mli && ocamlc -c pack.ml
TagsNo tags attached.
Attached Files

- Relationships
related to 0006305feedbackgarrigue Namespace pollution when using 'module type of' in an explicit interface for a pack 

-  Notes
(0011608)
shinwell (developer)
2014-05-30 15:15

Jacques, maybe a bug here?
(0011611)
garrigue (manager)
2014-05-31 16:01

Whether this is a bug or not is unclear.
The problem is that (module type of B) in the interface refers to a module A outside of the packed module (as discussed in PR#6305 and friend, there is no way to know when compiling pack.mli that B should refer to A in Pack rather than outside), and -pack (intentionally) does not preserve the connection between packed modules and their original names, as this would reintroduce the name space pollution -pack is trying to avoid.
To be more precise, the incompatibility is between Pack.A.t (in the packed module) and A.t (in the mli).

This problem could be avoided by applying the packing substitution to the export signature when checking inclusion, but this seems useless as we would still have the namespace pollution described in PR#6305.

- Issue History
Date Modified Username Field Change
2014-01-24 11:38 Julien Signoles New Issue
2014-05-30 15:15 shinwell Note Added: 0011608
2014-05-30 15:15 shinwell Assigned To => garrigue
2014-05-30 15:15 shinwell Status new => acknowledged
2014-05-31 15:49 garrigue Relationship added related to 0006305
2014-05-31 16:01 garrigue Note Added: 0011611
2014-07-16 17:34 doligez Target Version => 4.03.0+dev


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker