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.
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.
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.
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.
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.
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.
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.
I think this is more a problem for the build-system, and you can easily do this with
dune. Here a hierarchy:
lib directory, the
jbuild file is:
(libraries (m n))
m directory the
jbuild file is:
you write a similar file in the directory
n, then you go in the
lib directory, you run
jbuilder utop, and:
- : string = "submodule A of M"
- : string = "submodule b of M"
- : string = "submodule A of N"
- : string = "submodule B of N"
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.
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.
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).