Alessandro Baretta
2006-02-08 13:28:14 UTC
Gentlemen--most specifically Xavier,
Every other year I have mentioned on this list that I have encountered a module
name clash problem, rendering some bit of code unusable and my life very
miserable. It happened again today. Hence, this post, to help me relieve my
frustration.
Luckily, today I control one of the two modules whose names collide, so I can
easily overcome the problem by renaming one file and changing all relevant
references to it in a relativeley self-contained sub-project of my full source
tree. Were it otherwise, I'd be in trouble. Let me state that I am currently
managing a source tree comprising approximately ten man years of work and
236klocs as of today, including generated code. When a project grows to this
size, it is relatively easy to produce such name clashes.
The clashing modules are Liveness in the metanative.cmxa library of the
MetaOcaml project and a Liveness module in a PLC application based on my
AS/Xcaml. I realize that "liveness" is a meaningful word to a compiler author,
but it also is to a automation engineer. It is doubtful that either the
MetaOcaml team or I have a greater right to this name, and it is unreasonable to
renounce many useful words just because they might be of common interest.
Xavier's official position until now has been the following: "You guys have the
-pack option; use it." This is probably the best solution overall, but it is
hardly reconcilable with the fact that out there in the wild--and in my own
repository--there are truckloads and truckloads of code that don't use it and
that would need to be modified to use it, because of the need to explicity open
in the projects source files all referenced libraries. Hence, it is impossibile
for the build system to automatically manage namespacing issues.
Probably, all that ocaml lacks to properly handle namespacing is a -open
directive, telling the compiler to imply a "open Xxxx" at the beginning of all
.ml and .mli files on the command line. Given this compiler flag, the build
system could take care of everything.
I'm sure there are other ways to solve this issue, and I'm non really trying to
sell anyone my idea. As I stated, I'm just writing to relieve my frustration.
Alex
--
*********************************************************************
Ing. Alessandro Baretta
Studio Baretta
http://studio.baretta.com/
Consulenza Tecnologica e Ingegneria Industriale
Technological Consulting and Industrial Engineering
tel. +39 02 370 111 55
fax. +39 02 370 111 54
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Every other year I have mentioned on this list that I have encountered a module
name clash problem, rendering some bit of code unusable and my life very
miserable. It happened again today. Hence, this post, to help me relieve my
frustration.
Luckily, today I control one of the two modules whose names collide, so I can
easily overcome the problem by renaming one file and changing all relevant
references to it in a relativeley self-contained sub-project of my full source
tree. Were it otherwise, I'd be in trouble. Let me state that I am currently
managing a source tree comprising approximately ten man years of work and
236klocs as of today, including generated code. When a project grows to this
size, it is relatively easy to produce such name clashes.
The clashing modules are Liveness in the metanative.cmxa library of the
MetaOcaml project and a Liveness module in a PLC application based on my
AS/Xcaml. I realize that "liveness" is a meaningful word to a compiler author,
but it also is to a automation engineer. It is doubtful that either the
MetaOcaml team or I have a greater right to this name, and it is unreasonable to
renounce many useful words just because they might be of common interest.
Xavier's official position until now has been the following: "You guys have the
-pack option; use it." This is probably the best solution overall, but it is
hardly reconcilable with the fact that out there in the wild--and in my own
repository--there are truckloads and truckloads of code that don't use it and
that would need to be modified to use it, because of the need to explicity open
in the projects source files all referenced libraries. Hence, it is impossibile
for the build system to automatically manage namespacing issues.
Probably, all that ocaml lacks to properly handle namespacing is a -open
directive, telling the compiler to imply a "open Xxxx" at the beginning of all
.ml and .mli files on the command line. Given this compiler flag, the build
system could take care of everything.
I'm sure there are other ways to solve this issue, and I'm non really trying to
sell anyone my idea. As I stated, I'm just writing to relieve my frustration.
Alex
--
*********************************************************************
Ing. Alessandro Baretta
Studio Baretta
http://studio.baretta.com/
Consulenza Tecnologica e Ingegneria Industriale
Technological Consulting and Industrial Engineering
tel. +39 02 370 111 55
fax. +39 02 370 111 54
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs