Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004961OCaml~DO NOT USE (was: OCaml general)public2010-01-15 12:222016-12-12 17:06
Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version3.11.1 
Target VersionFixed in Version 
Summary0004961: module rename X = Y.
DescriptionHi. it would be nice to have a "module rename X = Y" feature. For instance, I have two Postgresql modules. One provided by the postgresql-ocaml package, and another one in my local code. I would like to write "module rename PGconv = Postgresql" so that the local Postgresql module is now refered as PGConv, and such that it *frees* the namespace in order to be able to refer to the Postgresql module of postgresql-ocaml as Postgresql.

Such a feature would be quite useful, as managing module name conflicts is rather painful in OCaml.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
yziquel (reporter)
2010-01-19 18:44
edited on: 2010-01-19 18:46

Perhaps an "open X as Y" syntax would be more convenient.

In the same spirit, it would be nice to have the following code being valid

type t
module X = struct
  type t
  let f : t -> .t = blah blah blah...

where .t would represent the type t outside of X, i.e. the first 'type t' declaration.

goswin (reporter)
2010-02-26 21:58

If you have 2 modules with the same name then it already is unclear, at least to the casual reader, which of the two you are refering too.

As to the suggestion of "open X as Y" that would still leave X (both of them) in the namespace. At least I would expect that. So I would expect and to now be the same. The shadowed other X would still be unaccessable. The "rename X as Y" would make it clearer that it removes X from the namespace and would be invalid or not

I feel that "open X as Y" can be written as "module Y = X".

And for your type shadowing problem you can use the following (confusing) syntax:

# module X = struct type parent_t = t type t let f : t -> parent_t = fun t -> Obj.magic 0 end;;

module X : sig type parent_t = t type t val f : t -> parent_t end

yziquel (reporter)
2010-02-28 16:49

I really want one module name to disappear.

Suppose you've got two modules A and B.A.

What I want is to write

rename A as C
open B

so that you have module C (the former A module) and module A (the former B.A) module.

More generally, it is somewhat surprising that modules, which are rather semantic in nature, are so tightly coupled with their names, which is a syntactic concept. I am not saying that the approach I proposed is the right one, but it would be nice to be able to have a more efficient way to manage module name clashes in OCaml.

As for the second problem, of type shadowing, the problem is indeed that you can only deal with this rather natural problem by using a confusing syntax. The code proposed by Goswin would look terrible in a .mli file with ocamldoc called upon it. Hence my suggestion of .t for the type in the parent module.
goswin (reporter)
2010-03-01 13:08

As long as the initial module names are distinct you can rename them to your liking. The original name won't disapear but that doesn't matter if you do it in the right order.

module C = A
module A = B.A (* or open B in this case *)

In other cases you might have to create a dummy name first to get the order right.

module T123 = A
module A = B
module B = T123

An actual rename you would only need when you have for example a module named Buffer and now you want to access the stdlibs Buffer. Or rather when someone else duplicates a module name and you have to work with that code.

shinwell (developer)
2016-12-12 17:06

The problem seems to be the use of libraries that are not packed or namespaced in some way. It is very unlikely that the renaming of modules in the manner suggested will ever be implemented---however, there are possible solutions involving the use of module aliases; and further improved namespacing support is likely to appear in the near future.

- Issue History
Date Modified Username Field Change
2010-01-15 12:22 yziquel New Issue
2010-01-19 18:44 yziquel Note Added: 0005230
2010-01-19 18:46 yziquel Note Edited: 0005230
2010-02-26 21:58 goswin Note Added: 0005253
2010-02-28 16:49 yziquel Note Added: 0005254
2010-03-01 13:08 goswin Note Added: 0005255
2011-06-01 16:43 doligez Status new => acknowledged
2016-12-12 17:06 shinwell Note Added: 0016974
2016-12-12 17:06 shinwell Status acknowledged => closed
2016-12-12 17:06 shinwell Resolution open => won't fix
2017-02-23 16:36 doligez Category OCaml general => -OCaml general
2017-03-03 17:55 doligez Category -OCaml general => -(deprecated) general
2017-03-03 18:01 doligez Category -(deprecated) general => ~deprecated (was: OCaml general)
2017-03-06 17:04 doligez Category ~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker