Name clash with stdlib

Learning
1

My library contains a module called UChar, which clashes Uchar module in stdlib. It does not affect to my library’s users, because the library is wrapped into a top-level module, but it causes failure of build process.

Before, I add -I option to the compiler and it worked, but now I want to refer Uchar inside of UChar (because it is now an alias to Uchar), it don’t work.

Do you have any idea on how to avoid this? I use macOS (that would be a reason). For the build I use jbuilder/Dune.

Your possible reactions and answers:

  • Can’t just remove UChar? – I want to retain UChar for backward compatibility
  • Don’t use macOS! – Can’t help. I can’t afford another PC and Mac works well for other purpose. Can’t change file system neither now.
  • Why on earth you choose the (almost) same module name to the one in stldlib?! – My library is older (much older) than stdlib’s Uchar.

To avoid this kind of accidents, I think it would be worthwhile to wrap all stdlib into a single module, say, Stdlib and implicitly open in the beginning of files/sessions.

2 Likes
2

Regarding wrapping the standard library - see https://github.com/ocaml/ocaml/pull/1010 which has been merged and will hopefully survive the trip to OCaml 4.07.

4 Likes
3

Yes, OCaml still needs namespaces. I have this need today, had it 10 years ago. Some people have come up with implementations but sadly they were never merged into the language.

A requirement of namespaces is that they can be used to identify a vendor, that is an organization or an individual that distributes multiple packages.

I apologize for the slightly off-topic rant. I thought this had to be written somewhere.

6 Likes
4

Honest question despite a very naïve one: how would namespaces differ from prefixing all your library modules with the library name (or shorthand) and offering a convenient global module that defines all your modules under a shorter name, as in batteries for instance?
I’ve worked with C++ and java namespaces long ago and do not remember them as significantly different, so I’ve always thought it was more a question of methodology than a missing feature.

5

Indeed, shouldn’t namespaces in ocaml be just modules, as namespaces in c++ are kind of classes? It would be very convenient to have directory hierarchy as module hierarchy, not just file = module.

6

Example:

I am vendor X, who distributes a module A and a module B separately, as different libraries in different opam packages. I want users to be able to install and use just A and refer to it as X.A. Nothing is known by the compiler about X.B because it’s not installed. Therefore this X can’t be a module since its full signature is unknown. X would be called a namespace because it solves name conflicts much like modules do, but unlike modules it doesn’t have a signature.

3 Likes
7

There is this namespace proposal. https://github.com/lpw25/namespaces. Not sure what stage this is in. Briefly reading it, the proposal seems to favor folders as a namespacing mechanism.

I am guessing this sort of issue will only be more common as ocaml usage increases and developing ocaml software more often means using packages from several vendors - which increases the chances of module name clashes.

8

I think this is more a problem for the build-system, and you can easily do this with dune. Here a hierarchy:

lib
|- jbuild
|- m
   |- jbuild
   |- a.ml
   |- b.ml
|- n
   |- jbuild
   |- a.ml
   |- b.ml

in you lib directory, the jbuild file is:

(jbuild_version 1)

(library
 ((name mylib)
  (libraries (m n))
  (wrapped false)))

in your m directory the jbuild file is:

(jbuild_version 1)

(library
 ((name m)))

you write a similar file in the directory n, then you go in the lib directory, you run jbuilder utop, and:

# M.A.s;;
- : string = "submodule A of M"

# M.B.s;;
- : string = "submodule b of M"

# N.A.s;;
- : string = "submodule A of N"

# N.B.s;;
- : string = "submodule B of N"
2 Likes
9

I see. But I’m a bit worried that something that looks so much like a module could in fact be either a module or a namespace. Wouldn’t that be better if namespaces appeared for what they are, ie basically a search path, for instance like X/A instead of X.A ? It would then be straightforward for the users what’s going on.

10

If we properly wrapped the library, I found the build error does not occur. So, my problem is resolved. Sorry for the noise.

But still packing stdlib is a good idea in my opinion.

11

I’m sure these issues can be resolved. Simply put, I’d like Janestreet to use a Janestreet namespace and have all their modules in there (and I’m hoping they’re honored that I picked them as an example).

1 Like