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

two names for same module are (wrongly) distinguished by the typechecker #5302

Closed
vicuna opened this issue Jun 27, 2011 · 8 comments
Closed

Comments

@vicuna
Copy link

vicuna commented Jun 27, 2011

Original bug ID: 5302
Reporter: rgrig
Status: closed (set by @xclerc on 2011-08-01T12:42:34Z)
Resolution: won't fix
Priority: normal
Severity: minor
Version: 3.13.0+dev
Category: ~DO NOT USE (was: OCaml general)
Duplicate of: #3775
Related to: #4049
Parent of: #3476

Bug description

The attached file does not compile.

Two simple variations of the same code do compile:

  • inlining the definition of module Int
  • moving the definition of Int outside of Util

File attachments

@vicuna
Copy link
Author

vicuna commented Jun 27, 2011

Comment author: pascal_cuoq

The error message I get:

$ ocamlc a.ml
File "a.ml", line 6, characters 29-43:
Error: This expression has type U.IntSet.t = Set.Make(U.Int).t
but an expression was expected of type
Util.IntSet.t = Set.Make(Util.Int).t

@vicuna
Copy link
Author

vicuna commented Jun 27, 2011

Comment author: @xclerc

In this example, it is sufficient to give the signature of "Util" explicitly.
The following compiles nicely.

module Util : sig
module Int : sig type t = int val compare : t -> t -> int end
module IntSet : Set.S with type elt = int
end = struct
module Int = struct type t = int let compare = compare end
module IntSet = Set.Make (Int)
end
module U = Util
let _ = Util.IntSet.empty == U.IntSet.empty

@vicuna
Copy link
Author

vicuna commented Jun 28, 2011

Comment author: rgrig

The following also compiles.

module Util = struct
module Int = struct type t = int let compare = compare end
module IntSet : Set.S = Set.Make (Int)
end
module U = Util
let _ = Util.IntSet.empty == U.IntSet.empty

@vicuna
Copy link
Author

vicuna commented Jul 27, 2011

Comment author: rgrig

Silly question: Does the current status (feedback) mean that you are waiting for me (the reporter) to answer some question? If so, I have no idea what the question is.

@vicuna
Copy link
Author

vicuna commented Jul 27, 2011

Comment author: @xclerc

Well, the implicit question is whether you still regard this as a bug.
From my point of view, it is not as functor application equality is
resolved namely (by comparing the paths) rather than structurally.

As shown by the examples in the notes your very problem can be
resolved by adding some type annotations in order to ensure that
the type checker use the same path for both modules.

@vicuna
Copy link
Author

vicuna commented Jul 27, 2011

Comment author: rgrig

Yes, I still regard it as a bug, although one with a simple-to-use workaround.

I do not want to think about how the compiler works; I want to think about what the program should mean.

If the program looks like
let x = E in
let y = x in
F
then I expect that x and y can be renamed to one-another within F without any observable effect (typechecking-wise and running-wise).

Similarly, if the program looks like
module X = E
module Y = X
F
then I expect that X and Y can be renamed to one-another within F without any observable effect. It is weird that now X and Y can be renamed to one-another but only for certain Es. It just doesn't seem like the content of E should matter at all.

@vicuna
Copy link
Author

vicuna commented Jul 27, 2011

Comment author: @xclerc

Just added some relationships to this bug to both classify it,
and try to convince you that what you consider a bug is most
probably a mere (well- and long-known) limitation of the
type system.

@vicuna
Copy link
Author

vicuna commented Jul 27, 2011

Comment author: rgrig

Thank you! It does look like a limitation-by-design.

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

1 participant