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

Explicit interface for a pack, "module type of" and type generativity #6304

Closed
vicuna opened this issue Jan 24, 2014 · 4 comments
Closed

Explicit interface for a pack, "module type of" and type generativity #6304

vicuna opened this issue Jan 24, 2014 · 4 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented Jan 24, 2014

Original bug ID: 6304
Reporter: Julien Signoles
Assigned to: @garrigue
Status: acknowledged (set by @mshinwell on 2014-05-30T13:15:17Z)
Resolution: open
Priority: normal
Severity: minor
Category: typing
Related to: #6305
Monitored by: @gasche @diml @hcarty @yakobowski

Bug description

Consider 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

@vicuna
Copy link
Author

vicuna commented May 30, 2014

Comment author: @mshinwell

Jacques, maybe a bug here?

@vicuna
Copy link
Author

vicuna commented May 31, 2014

Comment author: @garrigue

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

@github-actions
Copy link

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.

@github-actions github-actions bot added the Stale label May 13, 2020
@garrigue
Copy link
Contributor

Close it in favour of duplicate #6433, which has a better discussion.

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