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

module type of applied to module aliases #6336

Closed
vicuna opened this issue Mar 5, 2014 · 3 comments
Closed

module type of applied to module aliases #6336

vicuna opened this issue Mar 5, 2014 · 3 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented Mar 5, 2014

Original bug ID: 6336
Reporter: @lpw25
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2015-12-11T18:26:31Z)
Resolution: not a bug
Priority: normal
Severity: minor
Category: typing
Monitored by: @diml @hcarty

Bug description

It is potentially surprising that the following code compiles on trunk:

module M : sig
type 'a t = private { foo: 'a; bar: 'a }
val example : int t
end = struct
type 'a t = { foo: 'a; bar: 'a }
let example = {foo=0;bar=0}
end

module A = M

module type S = module type of A
module N : S = A
module U : S = A
let z = [N.example;U.example]

whilst the following does not:

module M : sig
type 'a t = private { foo: 'a; bar: 'a }
val example : int t
end = struct
type 'a t = { foo: 'a; bar: 'a }
let example = {foo=0;bar=0}
end

module type S = module type of M
module N : S = M
module U : S = M
let z = [N.example;U.example]

Since module A = M now introduces an alias, it seems that operations on A should behave like operations on M, but this is not the case for module type of which returns a strengthened signature from A but a weakened signature from M.

Of course if module type of returned the strengthened version then it would already do the right thing, but since it doesn't, it might be best if module type of treated module aliases specially.

@vicuna
Copy link
Author

vicuna commented Mar 6, 2014

Comment author: @garrigue

This result is not surprising: unrolling the signature of an alias results in the strengthened signature of the original module, so that taking "module type of" this signature will give you this already strengthened signature.
This is just the standard behavior for module aliases.
This is in contrast with applying "module type of" to the original module, which will give you the signature of the module, but not strengthened.
In both cases, "module type of" does no strengthening.
Indeed "module type of" is a hack, and the result is not strictly functional, but this is by design.

@vicuna
Copy link
Author

vicuna commented Mar 6, 2014

Comment author: @lpw25

This result is not surprising: unrolling the signature of an alias results in the strengthened signature of the original module, so that taking "module type of" this signature will give you this already strengthened signature.

Indeed, I didn't find it surprising, but the people who brought it to my attention did, and I can see their point. When you tell people that A is an alias for B, they assume that A and B can be used interchangeably. For the most part this reasoning works with module aliases, but module type of is a place where that reasoning breaks down.

Is there any particular reason to not treat module aliases specially in module type of by fetching the weakened version of the type of the module that is aliased?

@vicuna
Copy link
Author

vicuna commented Apr 4, 2014

Comment author: @garrigue

Is there any particular reason to not treat module aliases specially in module type of by fetching the weakened version of the type of the module that is aliased?

Backward compatibility.
The first version of your code is accepted by previous versions of OCaml (post 3.12, of course), and the second version is refused.

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