Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] camlimages vs. labltk
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Damien Doligez <Damien.Doligez@i...>
Subject: Re: [Caml-list] naming conflicts (was: camlimages vs. labltk)
On Sunday, March 30, 2003, at 12:38 PM, Sven Luther wrote:

> But then, maybe i am just being stupid and completely misunderstand the
> problem or something such, please enlighten me if this is the case.

Judging from your and Chris Hecker's mail, I think it's my fault for
not explaining clearly what I have in mind.  Let me try again.

First of all, let me say that I am looking for a complete solution
to the problem, not just a quick fix that works most of the time.
 From this point of view, there is no difference between modules
and libraries: if there are naming conflicts between modules, there
will also be conflicts between libraries.

I'll give two examples of what I think the problem is.

First example:
I am building a program D, which uses libraries B and C.  B uses
another library, A.  C also uses another library, A.  But these are
not the same A, so I have a name conflict.  I don't want to change
the source code of B or C (because I am not the author, and updating
to a new version is much harder if I use modified libraries).

So I need to rename the A used by B, and I need to tell B to use
A under this new name.  This is why I need to rename imports as
well as exports.

Second example (somewhat artificial):
I am doing comparative benchmarks of two versions of library A.
I'd like to wrap up everything into one O'Caml program, so I need
to be able to link two different versions of A, and to call them
under two different names.

I don't need to rename imports for this one, but I think it
illustrates the problem with namespaces: are you going to demand
that every author of every library uses a different namespace for
each version of the library ?


Now that I think about it, I think both problems could be solved
by changing toplevel modules into functors (instead of modules with
free variables).  Then we only need a small linking language to tell
which export to use to satisfy each import.  With suitable defaults
(an import is satisfied by the export of the same name), this could
be made compatible with the current system.

-- Damien

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners