[Caml-list] camlimages vs. labltk

[Caml-list] camlimages vs. labltk

[Shivkumar Chandrasekaran]

I observed that both camlimages and labltk have a module named "Image". 
Any idea how I can get both to co-exist? Thanks.

--shiv--

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[Alessandro Baretta]

Shivkumar Chandrasekaran wrote:
 > I observed that both camlimages and labltk have a module 
named "Image".
 > Any idea how I can get both to co-exist? Thanks.


This is a problem that comes up every so often: module 
namespace cluttering. Some time ago I had pointed a name 
clash between the Meta module in findlib and in the dynlink 
library. Namespace clashes are bound to come up now and then 
until the caml team introduces a namespace construct in the 
language.

We already had a fairly long thread on the subject, and I 
don't think theres much more to be said, so I'll just send 
you a link to it.

http://caml.inria.fr/archives/200209/msg00232.html

Alex

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[Sven Luther]

On Wed, Mar 26, 2003 at 09:25:48AM +0100, Alessandro Baretta wrote:
> 
> Shivkumar Chandrasekaran wrote:
> > I observed that both camlimages and labltk have a module 
> named "Image".
> > Any idea how I can get both to co-exist? Thanks.
> 
> 
> This is a problem that comes up every so often: module 
> namespace cluttering. Some time ago I had pointed a name 
> clash between the Meta module in findlib and in the dynlink 
> library. Namespace clashes are bound to come up now and then 
> until the caml team introduces a namespace construct in the 
> language.

There is already the -pack option, and the right thing to solve this
problem would be to build all libraries to make usage of it (if
possible). So you would have a CamlImage.Image module and a Labltk.Image
module, which work pretty well.

Now, library writters just need to modify their build system to take
advantage of it, starting by the INRIA released libraries, especially
the ones provided by the ocaml tarball directly like labltk.

Friendly,

Sven Luther

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[Alessandro Baretta]

Sven Luther wrote:
> On Wed, Mar 26, 2003 at 09:25:48AM +0100, Alessandro Baretta wrote:
> 
> 
> There is already the -pack option, and the right thing to solve this
> problem would be to build all libraries to make usage of it (if
> possible). So you would have a CamlImage.Image module and a Labltk.Image
> module, which work pretty well.
> 
> Now, library writters just need to modify their build system to take
> advantage of it, starting by the INRIA released libraries, especially
> the ones provided by the ocaml tarball directly like labltk.

Sven, someone on this list wisely pointed out that you buy 
nothing by telling someone else "You don't need that 
feature". We do need namespaces. It might not be paramount: 
I'm pretty sure there is something more important to be done 
at Inria. But, please, don't tell me that -pack will cure 
cancer, promote democracy, establish universal peace, and 
make my teeth look whiter. Packing does not allow 
factorizing your code--bytecode, actually--in small reusable 
units. One big .cmo is not as flexible as a .cma. I simply 
might not want to link all of a library: what if it's 
modules contain side-effects? So -pack is good, but 
namespaces are still a necessary feature to Ocaml as to any 
industrial level programming language.


Cheers to all Caml riders,
Alex

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[Sven Luther]

On Wed, Mar 26, 2003 at 10:00:03AM +0100, Alessandro Baretta wrote:
> 
> 
> Sven Luther wrote:
> >On Wed, Mar 26, 2003 at 09:25:48AM +0100, Alessandro Baretta wrote:
> >
> >
> >There is already the -pack option, and the right thing to solve this
> >problem would be to build all libraries to make usage of it (if
> >possible). So you would have a CamlImage.Image module and a Labltk.Image
> >module, which work pretty well.
> >
> >Now, library writters just need to modify their build system to take
> >advantage of it, starting by the INRIA released libraries, especially
> >the ones provided by the ocaml tarball directly like labltk.
> 
> Sven, someone on this list wisely pointed out that you buy 
> nothing by telling someone else "You don't need that 
> feature". We do need namespaces. It might not be paramount: 

And the module system offers it. The problem you have is not about
namespace, but because the current namespace solution has a few
technical problems that need to be solved. The module system provides a
theoretically and well proved way of doing namespace management, and you
want to put it aside for a java-inspired quick hack because of
technicalities ?

> I'm pretty sure there is something more important to be done 
> at Inria. But, please, don't tell me that -pack will cure 
> cancer, promote democracy, establish universal peace, and 
> make my teeth look whiter. Packing does not allow 

It is the right solution for the current problem. The problem is that
you want to solve the namespace issue, and the correct way of doing this
is by moving the modules of a library to be submodules of the library
module or something such. This can be achieved best with the -pack
option right now, even if there are a few problems with it.

> factorizing your code--bytecode, actually--in small reusable 
> units. One big .cmo is not as flexible as a .cma. I simply 
> might not want to link all of a library: what if it's 
> modules contain side-effects?

Well, if you look at the C libraries, they are either static libraries,
where you get ride of the cruft with strip, or dynamically loaded shared
libraries. I don't think there is a strip equivalent, for ocaml (be it
bytecode or native code, not sure about native code though) but the
current inclusion granularity is at the .cmo level. This may be changed
in the future though. As for dynamically loaded, shared ocaml code, this
is also not yet available, but is also a requested feature, which would
make the above stripping unnecessary, i think.

So, the problem is not so much that we need a namespace solution, we
clearly have one already, but that we need smaller granularity in code
inclusion in .cmo or .cmx, or a strip utility or functionality which can
be called by ocamlc at link time and/or true dynamically linked and
shared libraries. Both of these things have often be requested, but
cause some problems, if i understood right what the ocaml team has to
say about it.

As for side-effects, i didn't really think about that, but i guess that
you could easily implement the modules so that the side effect do happen
when you call a module initialization function or something such. I
don't think it really is good practice to use toplevel global side
effect for library code anyway.

> So -pack is good, but 
> namespaces are still a necessary feature to Ocaml as to any 
> industrial level programming language.

No, the namespace feature is already there, altough not much used in
reality, the problems are elsewhere.

Friendly,

Sven Luther

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[Alessandro Baretta]

Sven Luther wrote:
> On Wed, Mar 26, 2003 at 10:00:03AM +0100, Alessandro Baretta wrote:
> 
>>
>>Sven Luther wrote:

>>Sven, someone on this list wisely pointed out that you buy 
>>nothing by telling someone else "You don't need that 
>>feature". We do need namespaces. It might not be paramount: 

> As for side-effects, i didn't really think about that, but i guess that
> you could easily implement the modules so that the side effect do happen
> when you call a module initialization function or something such. I
> don't think it really is good practice to use toplevel global side
> effect for library code anyway.

We now have a new language feature: it's called
You Don't Need It (TM), patent pending ;)

>>So -pack is good, but 
>>namespaces are still a necessary feature to Ocaml as to any 
>>industrial level programming language.
> 
> 
> No, the namespace feature is already there, altough not much used in
> reality, the problems are elsewhere.

Modules are a very powerful theoretical instrument with a 
profound algebraic meaning, rooted in category theory. This 
is all very good, and I appreciate it. But namespaces are 
something _ELSE_. And they too are a good thing to have. Why 
don't we just stop this "You don't need it thing" about any 
language feature we don't already have. Ocaml is a cool 
language. It's my primary language for developing business 
applications. I earn a living with it. I know what I need 
and what I don't need. Namespaces are a useful tool, aside 
from the algebraically based module system: they simply 
provied a means for mangling module names so as to avoid 
name clashes.

There are many different ways of implementing a namespace 
system. We need to think of an implementation orthogonal to 
the module system, so as to add functionality without 
introducing conflicts with the module system. I would 
appreciate a lot more a -namespace option to ocamlmklib than 
a -pack option to ocamlc. This feature would have to go with 
such additional language constructs such as an "in" operator 
for namespace resolution. Such language constructs have 
already been implemented as camlp4 syntax extensions and are 
already available out there.

> Friendly,
> 
> Sven Luther
> 

Cheers,
Alex

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[Sven Luther]

On Wed, Mar 26, 2003 at 12:24:56PM +0100, Alessandro Baretta wrote:
> 
> 
> Sven Luther wrote:
> >On Wed, Mar 26, 2003 at 10:00:03AM +0100, Alessandro Baretta wrote:
> >
> >>
> >>Sven Luther wrote:
> 
> >>Sven, someone on this list wisely pointed out that you buy 
> >>nothing by telling someone else "You don't need that 
> >>feature". We do need namespaces. It might not be paramount: 
> 
> >As for side-effects, i didn't really think about that, but i guess that
> >you could easily implement the modules so that the side effect do happen
> >when you call a module initialization function or something such. I
> >don't think it really is good practice to use toplevel global side
> >effect for library code anyway.
> 
> We now have a new language feature: it's called
> You Don't Need It (TM), patent pending ;)

Hey, you don't need to be sarcastic.

Tell me a legitimate reason to use side-effects in library top-level
would you, especially if you think that such a library may in the future
be shared, dynamically loaded and such.

> >>So -pack is good, but 
> >>namespaces are still a necessary feature to Ocaml as to any 
> >>industrial level programming language.
> >
> >
> >No, the namespace feature is already there, altough not much used in
> >reality, the problems are elsewhere.
> 
> Modules are a very powerful theoretical instrument with a 
> profound algebraic meaning, rooted in category theory. This 
> is all very good, and I appreciate it. But namespaces are 
> something _ELSE_. And they too are a good thing to have. Why 
> don't we just stop this "You don't need it thing" about any 
> language feature we don't already have. Ocaml is a cool 
> language. It's my primary language for developing business 
> applications. I earn a living with it. I know what I need 
> and what I don't need. Namespaces are a useful tool, aside 
> from the algebraically based module system: they simply 
> provied a means for mangling module names so as to avoid 
> name clashes.

So please tell me, what is it that namespace give you that the module
system don't provide already ? And what is the point in mangling module
names ? Do you really prefer a LabltkImage module over Labltk.Image ?
Which one makes more sense to you ?

> There are many different ways of implementing a namespace 
> system. We need to think of an implementation orthogonal to 
> the module system, so as to add functionality without 
> introducing conflicts with the module system. I would 
> appreciate a lot more a -namespace option to ocamlmklib than 
> a -pack option to ocamlc. This feature would have to go with 

Ok, you would want to have the pack option done at library generation
time, i agree with you, i don't really like the way it is currently done
(to generate a huge .cmo from multiple ones), and much would prefer to
have a .cma generated from multiple .cmo, with the -pack option (or the
-namespace, or whatever you would call it). Ideally, this would be the
default, so we would not have to worry about libraries not doing it.

> such additional language constructs such as an "in" operator 
> for namespace resolution. Such language constructs have 

What about the '.' ? Like in Labltk.Image ?

> already been implemented as camlp4 syntax extensions and are 
> already available out there.

Sure, but this is just syntax, what is important here is not so much
what you call it, but what it does.

Friendly,

Sven Luther

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[Chris Hecker]

I think this thread is a misunderstanding masquerading as an argument.

Alex, I think people (well, I do at least :) want to hear what the 
differences between a namespace and the module system are.  It seems on the 
face of it that fixing pack's implementation would solve the namespace 
problem (this was Sven's thought as well), but you don't think so (or think 
it's the wrong way to fix it), and I'd like to understand why, since you've 
obviously thought about it a bunch.

Thanks,
Chris

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[Alessandro Baretta]

Chris Hecker wrote:
> 
> I think this thread is a misunderstanding masquerading as an argument.
> 
> Alex, I think people (well, I do at least :) want to hear what the 
> differences between a namespace and the module system are.  It seems on 
> the face of it that fixing pack's implementation would solve the 
> namespace problem (this was Sven's thought as well), but you don't think 
> so (or think it's the wrong way to fix it), and I'd like to understand 
> why, since you've obviously thought about it a bunch.

I have been discussing this privately with Sven. I didn't 
mean to start another thread on the subject, because I knew 
that inevitably it would lead to big waste of time.

As I have mentioned already, I do not think namespaces are a 
paramount feature in any language. Sven correctly pointed 
out that C is a pretty successful language and it does not 
have namespaces. Of course, this is no excuse.

Namespaces address the issue of resolving, or mapping if you 
prefer, identifiers--actually, module names--to module 
objects--that is to pieces of code, bytecode or native 
equivalently.

In such languages as C or Ocaml, where there are no 
namespaces, this mapping is simply function from strings to 
pieces of code. I argue that this mapping gets a little 
clumsy--and this is common experience--when you have a lot 
of modules, that is, when you have a lot of distinct pieces 
of code which you want to identify indipently of each other.

Module encapsulation à la -pack addresses a different issue. 
Packing eliminates the name clashes by reducing the number 
of distinct modules. A lot of small modules are packed into 
one big one, and, voilà, the name clashes are gone. Yes, but 
this is a side effect. The main effect is that you get one 
big chunk of code which can no longer be refactored into its 
individual components: problems arise whenever one of the 
packed modules defines values which, upon definition, 
immediately perform computations. Even functional values 
could be defined in such a way as to engender a computation.

let f' x = ...

let f =
   let t = Hashtbl.create 1024 in
   fun x -> try Hashtbl.find t x with Not_found ->
     let y = f' x in
       Hashtbl.add x y; y

C has a powerful stripping feature because all computations 
start from main(), so by apply a graph traversal algorithm 
you can figure exactly what functions are called and what 
are not. But in our case computations can arise anywhere. 
This is why ocamlc links all modules that are passed to it, 
regardless of whether they are actually referenced anywhere 
else.

Do you see what the problems are with the module system? The 
module system is great for decomposing a problem into 
reusable units, but the units become much less versatile if 
they are packed together.

Namespace are much more "lightweight" feature. They address 
a specific problem: name clashes. They having nothing to do 
with problem factorization or generic programming. Names 
exist at a syntactic level, so the solution to a problem 
pertaining to identifier names must exist at a syntactic level.

Modules relate to sematics. Namespaces relate to syntax. 
Hence, they are orthogonal concepts. It's that simple.

Basically, the namespace feature expands the resolution 
scheme from names to module objects by adding one formal 
parameter to this mapping. If you'll allow me to use an 
pseudo-Caml syntax, I could say that we have a function
resolution : ~name:string -> module_object

We could (should?) have a mapping
resolution : ~space:string -> ~name:string -> module_object

I hope the pseudo-code I used helped make my point clearer 
rather than more obscure.

Alex

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[David Brown]

On Wed, Mar 26, 2003 at 10:08:00PM +0100, Alessandro Baretta wrote:

> Module encapsulation ? la -pack addresses a different issue. 
> Packing eliminates the name clashes by reducing the number 
> of distinct modules. A lot of small modules are packed into 
> one big one, and, voil?, the name clashes are gone. Yes, but 
> this is a side effect. The main effect is that you get one 
> big chunk of code which can no longer be refactored into its 
> individual components: problems arise whenever one of the 
> packed modules defines values which, upon definition, 
> immediately perform computations. Even functional values 
> could be defined in such a way as to engender a computation.

I think talking about namespaces is addressing the wrong problem.
Namespaces are merely a subset of the functionality already in the
module system.  They are usually put into languages that don't have good
module systems.

The -pack option is an attempt (in my impression a poor one) to solve a
different problem, easier separate compilation.  The functionality of
-pack could also be done (more difficulty) by choosing weird names
within the parent module, and having a single module encapsulate
everything.  I've seen code that does it this way.

If I get some spare time, I may try implementing the suggestion I gave
before, which I think is a nice elegant solution that doesn't change the
syntax or grammar of the language at all.  Here it is, boiled down:

Say for example, I want a large system Mylib, in it I want three
submodules: Mylib.Types, Mylib.Helper, Mylib.Process.  My proposal is to
have the following files:

   mylib.ml, mylib.mli  - might be empty if nothing is declared at the top.

   mylib-types.mli mylib-types.ml
   mylib-helper.mli mylib-helper.ml
   mylib-process.mli mylib-process.ml

When compiling other code, a reference to Mylib.Helper.foo will first
check for a mylib-helper.cmi, and then in mylib.cmi (in case the module
is defined there).

GHC (Haskell) does something similar to this.  To do it, some though
will have to be put into the exact semantics, this is just the general
idea.

Dave Brown

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[Chris Hecker]

>Do you see what the problems are with the module system?

Okay, let me restate your point and you can tell me if I got it.  You're 
saying the module system is bad for namespacing because it has the semantic 
of initializing all of its values without necessarily being referenced by 
the main program.  In other words, if I link in Foo, then Foo.myval has to 
be initialized or else the semantics of the module system are broken (side 
effects won't take place, etc.).  So, you can't use pack because pack 
implies a single large module, and the semantics above say you have to link 
and run all of the submodules in order for it to be a "real ocaml 
module".  And, there's no semantic for having some submodules not linked 
in, nor any way to specify that.  Right?

By contrast, cma libraries are different, in that the modules in them 
aren't linked unless they're referenced, right?  So, there is some 
precedent and process for demand based linking (as opposed to always 
linking everything on the link line).

Assuming we're on the same page about all of the above, do you think the 
syntax of the module system should or should not be overloaded for namespaces?

It seems like there are a couple different options:

1.  relax the semantics of module inclusion/initialization so that -pack 
can simultaneously provide the nested module syntax of Package.Foo but it 
doesn't have to link all of the submodules, like a cma

2.  define a new namespace system and syntax (or reuse the module syntax, 
not sure what the issues are there)

Are there any other options?  Did I get all of that right?

I agree that if the module semantics make it so that pack must link all 
submodules and run all initialization then it's too heavyweight and it 
either needs to be changed or there needs to be a new system.

Chris


-------------------
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

Re: [Caml-list] camlimages vs. labltk

[Alessandro Baretta]

Chris Hecker wrote:
> 
>> Do you see what the problems are with the module system?
> 
> 
> Okay, let me restate your point ...  Right?
> 

Yes. I'm glad I made my point clear.

> 
> Assuming we're on the same page about all of the above, do you think the 
> syntax of the module system should or should not be overloaded for 
> namespaces?

It doesn't really matter to me. I don't advocate the 
explicit use of the "namespace" keyword. I don't care at 
all, so long as naming problems are kept at the naming level 
and linking problems at the linking level.

> It seems like there are a couple different options:
> 
> 1.  relax the semantics of module inclusion/initialization so that -pack 
> can simultaneously provide the nested module syntax of Package.Foo but 
> it doesn't have to link all of the submodules, like a cma

I think this solution is unduly complex to implement, but 
then again, I am a caml rider, not a caml breeder...

> 2.  define a new namespace system and syntax (or reuse the module 
> syntax, not sure what the issues are there)

This is my suggestion: use a minor backward compatible 
syntax extension to allow for namespace use.

> Are there any other options?  Did I get all of that right?

Not that I know of.

> I agree that if the module semantics make it so that pack must link all 
> submodules and run all initialization then it's too heavyweight and it 
> either needs to be changed or there needs to be a new system.

Right.

Cheers, Chris.

Alex

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[David Brown]

On Fri, Mar 28, 2003 at 06:33:56AM +0100, Alessandro Baretta wrote:

> This is my suggestion: use a minor backward compatible 
> syntax extension to allow for namespace use.
> 
> >Are there any other options?  Did I get all of that right?
> 
> Not that I know of.

Leave the module syntax alone, and just modify the compiler a little bit
to allow submodules to exist in separate files.

Dave

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[Damien Doligez]

On Thursday, March 27, 2003, at 08:46 PM, Chris Hecker wrote:

> It seems like there are a couple different options:
>
> 1.  relax the semantics of module inclusion/initialization so that 
> -pack can simultaneously provide the nested module syntax of 
> Package.Foo but it doesn't have to link all of the submodules, like a 
> cma
>
> 2.  define a new namespace system and syntax (or reuse the module 
> syntax, not sure what the issues are there)
>
> Are there any other options?  Did I get all of that right?

How about a solution based on renaming ?  Let's say I have two modules
from different programmers, both named "Mylib", and I want to use them
in my program.  I cannot because the module system does not allow two
different modules with the same name to coexist.  The obvious solution
is a tool that renames one of the Mylib modules.  Then I can use both
modules in one program.

It becomes a little more complex when you consider that a module also
imports other modules, referenced by their names.  For example, I can
have (in addition to the two "Mylib" modules) another pair of modules,
Extlib and Superlib, written by two other programmers, and I want to
use them both in my program.  And Extlib uses one of the Mylib, Superlib
uses the other one.  Now if I rename the second Mylib into Mylib2,
I also have to tell Superlib to use Mylib2 instead of Mylib.

So I need a tool to rename modules, both as exports and as imports,
then I can use any module I want, without changing anything in the
language, and without the need for a universal naming scheme.

-- 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

Re: [Caml-list] camlimages vs. labltk

[Sven Luther]

On Fri, Mar 28, 2003 at 03:10:04PM +0100, Damien Doligez wrote:
> On Thursday, March 27, 2003, at 08:46 PM, Chris Hecker wrote:
> 
> >It seems like there are a couple different options:
> >
> >1.  relax the semantics of module inclusion/initialization so that 
> >-pack can simultaneously provide the nested module syntax of 
> >Package.Foo but it doesn't have to link all of the submodules, like a 
> >cma
> >
> >2.  define a new namespace system and syntax (or reuse the module 
> >syntax, not sure what the issues are there)
> >
> >Are there any other options?  Did I get all of that right?
> 
> How about a solution based on renaming ?  Let's say I have two modules
> from different programmers, both named "Mylib", and I want to use them
> in my program.  I cannot because the module system does not allow two
> different modules with the same name to coexist.  The obvious solution
> is a tool that renames one of the Mylib modules.  Then I can use both
> modules in one program.
> 
> It becomes a little more complex when you consider that a module also
> imports other modules, referenced by their names.  For example, I can
> have (in addition to the two "Mylib" modules) another pair of modules,
> Extlib and Superlib, written by two other programmers, and I want to
> use them both in my program.  And Extlib uses one of the Mylib, Superlib
> uses the other one.  Now if I rename the second Mylib into Mylib2,
> I also have to tell Superlib to use Mylib2 instead of Mylib.
> 
> So I need a tool to rename modules, both as exports and as imports,
> then I can use any module I want, without changing anything in the
> language, and without the need for a universal naming scheme.

Does this not sound as a ugly hack ? 

Would it not be easier to have something akin to -pack, but without its
technical problems, and have each library pack its module into a
namespace propper to this library ?

If all library did this by default, at library build time, then there
would be no need to rename the imports, since those imports would
already have the modified (that is Library.Module) names ?

Friendly,

Sven Luther

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[Damien Doligez]

On Friday, March 28, 2003, at 04:00 PM, Sven Luther wrote:

> Does this not sound as a ugly hack ?

Not to me...

> Would it not be easier to have something akin to -pack, but without its
> technical problems, and have each library pack its module into a
> namespace propper to this library ?

How do you make sure that two different libraries never use the same
namespace ?  And if I need to use two versions of the same library
in my program, how do you make sure that two versions of the same
library never use the same namespace ?

> If all library did this by default, at library build time, then there
> would be no need to rename the imports, since those imports would
> already have the modified (that is Library.Module) names ?

You can't avoid renaming of imports unless you have a centralized
allocation of namespaces, and _that_ sounds like an ugly hack to me.

-- 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

Re: [Caml-list] camlimages vs. labltk

[Sven Luther]

On Sun, Mar 30, 2003 at 12:06:27PM +0200, Damien Doligez wrote:
> On Friday, March 28, 2003, at 04:00 PM, Sven Luther wrote:
> 
> >Does this not sound as a ugly hack ?
> 
> Not to me...

Ok, ...

> >Would it not be easier to have something akin to -pack, but without its
> >technical problems, and have each library pack its module into a
> >namespace propper to this library ?
> 
> How do you make sure that two different libraries never use the same
> namespace ?  And if I need to use two versions of the same library
> in my program, how do you make sure that two versions of the same
> library never use the same namespace ?

Because you use something similar to the -pack option, each module
inside a library would be qualified by the library name, so the only
reason there could be a namespace conflict would be if two library used
the same name (like if ocamltk and labltk both used Tk. or both mlgtk
and lablgtk used Gtk.).

If there is such a conflict, either the people doing the conflicting
libraries discuss among themselves to solve the problem, either by one
of them renaming their lib or both of them merging , or some higher
authority (the ocaml team, a ocaml standardization comitee, a consensus
reached on the ocaml mailing list) takes some decision on on which way
the name should go. But still, i believe the name clash will pretty much
be extremely rare, since they would occur only with the names of the
library, not with the modules inside the libraries.

Now, i understand that the -pack option is not technically ready for
such a solution, if you consider that you have to link all modules of
the library inside one huge .cmo, which has to be included whole anytime
you use it. But i think that the above is the right solution to the
naming problem, and if i remember well, some members of the ocaml team
also seemed to be of that opinion last time this was discussed.

> >If all library did this by default, at library build time, then there
> >would be no need to rename the imports, since those imports would
> >already have the modified (that is Library.Module) names ?
> 
> You can't avoid renaming of imports unless you have a centralized
> allocation of namespaces, and _that_ sounds like an ugly hack to me.

I still don't understand what would have been renamed. Let's say a
module A inside a library foo imports a module B from library bar.

right now, we have the following :

  A imports B

this causes problem if you want to link with another library
which also has a module named B, or if you wish to name your own module
B.

now, if all modules of the library would be submodules of the library,
then we would have :

  Foo.A imports Bar.B

And now, another library zzz could have a module called B, which would
be accesed as Zzz.B, and there would be no need to rename the imports.
And even the personal module could either be plain B, or Personal.B or
something.

Sure, this displace the problam to library names instead of module
names, but still, there are much less libraries around than there are
modules.

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

Friendly,

Sven Luther

-------------------
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

Re: [Caml-list] naming conflicts (was: camlimages vs. labltk)

[Damien Doligez]

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

Re: [Caml-list] naming conflicts (was: camlimages vs. labltk)

[Benjamin C. Pierce]

> 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.

Wouldn't this create all sorts of problems with coherence (requiring
sharing declarations to fix)?  

The big difference between a functor and a module with a free variable is
that if you have *two* modules and you see the same variable name
occuring in them, you can be sure that, at link time, these names will
get bound to the same module, so no need for sharing declarations.  If
you change to functors (naively, anyway), you lose this guarantee.
 
     - B


-------------------
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

Re: [Caml-list] naming conflicts (was: camlimages vs. labltk)

[Chris Hecker]

>First example:
>Second example (somewhat artificial):

Right, both of those jibe with what I thought you were saying.  I don't 
know enough to understand your functor solution, but -pack could also be 
used to solve both of these problems, if it did a real partial-link.  In 
other words, if I -pack B and A, and B uses a module A, then B's imports 
should be resolved to the A that it got packed with.  I don't know if this 
is simpler or more complex than your functor solution, but this one at 
least could still be handled by current partial linking tools (which is 
what -pack uses right now).  In fact, this might already happen with pack, 
since you can -pack modules that refer to other modules, and since they're 
now in a super-module, the semantics are that they should still refer to 
the submodules at the same scope.  So, this should already work with -pack, 
no?  If so, then the cmo/cma partial linking thing is the only thing wrong 
with -pack from both a package and namespace manager perspective.

Or am I missing something obvious?

Chris

-------------------
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

Re: [Caml-list] naming conflicts (was: camlimages vs. labltk)

[Damien Doligez]

On Tuesday, April 1, 2003, at 09:51 PM, Chris Hecker wrote:

> In other words, if I -pack B and A, and B uses a module A, then B's 
> imports should be resolved to the A that it got packed with.

I think we're in violent agreement here.  Then my point simply becomes 
that
we need to rename B's imports to get this result.  Making this renaming
implicit or explicit then becomes a matter of design.


> In fact, this might already happen with pack, since you can -pack 
> modules that refer to other modules, and since they're now in a 
> super-module, the semantics are that they should still refer to the 
> submodules at the same scope.  So, this should already work with 
> -pack, no?

Yes, but that's because -pack actually performs a link of the packed
modules.  It renames B's imports by resolving them.

>   If so, then the cmo/cma partial linking thing is the only thing 
> wrong with -pack from both a package and namespace manager > perspective.

If you want -pack to produce a cma (i.e. a collection of independent 
modules),
then you have to rename A both as an export and as B's import.
Actually, that's not quite true.  In bytecode, you can link several 
modules
with the same name in a program.  If you take care to link them in the 
right
order, you can make sure that other modules' imports are resolved by the
right versions.  But in native code this trick doesn't work.

-- 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

Re: [Caml-list] camlimages vs. labltk

[Chris Hecker]

>How do you make sure that two different libraries never use the same
>namespace ?  And if I need to use two versions of the same library
>in my program, how do you make sure that two versions of the same
>library never use the same namespace ?

Are you saying because they cross reference each other, or because they are 
the same name?  If -pack was changed to work in the way we've been talking 
about (basically, the submodules are in a cma not cmo), then the user of 
the libraries could just pack them in different outer names, no?  In other 
words, -pack would be able to be used as a namespace renamer, or as a 
library packer, etc., but it has the advantage of being a single solution 
as opposed to having a namespace and a pack syntax/semantic.  If you've 
got  cross referencing, say A uses B version 1 and you want to use B 
version 2, then you pack A and Bv1 into a single ABv1 library, and you use 
B and it should "just work".

Assuming it's not impossible to make -pack work this way (not forcing link 
of all submodules), it seems better to have a single solution as opposed to 
multiple.  Unless I'm missing something?

Chris

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[Alessandro Baretta]

Damien Doligez wrote:
> On Thursday, March 27, 2003, at 08:46 PM, Chris Hecker wrote:
> 
>> Are there any other options?  Did I get all of that right?
> 
> 
> How about a solution based on renaming ?  Let's say I have two modules
> from different programmers, both named "Mylib", and I want to use them
> in my program.  I cannot because the module system does not allow two
> different modules with the same name to coexist.  The obvious solution
> is a tool that renames one of the Mylib modules.  Then I can use both
> modules in one program.

I glad to see there is some convergence towards a namespace 
scheme for the name clash problem. Module renaming is akin 
to the namespacing scheme I proposed earlier, based on a 
compile time or link time module name mangling. There are 
minor syntactic issues to be addressed in order to allow 
user code to explicitly specify the namespace name used at 
compile time or link time; however, a means has to be 
provided to allow for automatic build time namespace 
resolution, for example by adding a -N option to ocamlc, 
akin to -I. -I allows us to add a directory to the 
filesystem search path used by ocamlc. -N could add a 
namespace to a namespace search path. The namespace search 
path could then be searched sequentially for matching module 
names.

Alex

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[Shivkumar Chandrasekaran]

Is there a simple work-around for now that I could do. Something like:

cd /usr/local/lib/ocaml/camlimages
ocamlc -pack camlimages.cmo *.cmo

???? I am guessing this will not cut it. Thanks,

--shiv--



On Wednesday, March 26, 2003, at 12:33 AM, Sven Luther wrote:

> On Wed, Mar 26, 2003 at 09:25:48AM +0100, Alessandro Baretta wrote:
>>
>> Shivkumar Chandrasekaran wrote:
>>> I observed that both camlimages and labltk have a module
>> named "Image".
>>> Any idea how I can get both to co-exist? Thanks.
>>
>>
>> This is a problem that comes up every so often: module
>> namespace cluttering. Some time ago I had pointed a name
>> clash between the Meta module in findlib and in the dynlink
>> library. Namespace clashes are bound to come up now and then
>> until the caml team introduces a namespace construct in the
>> language.
>
> There is already the -pack option, and the right thing to solve this
> problem would be to build all libraries to make usage of it (if
> possible). So you would have a CamlImage.Image module and a 
> Labltk.Image
> module, which work pretty well.
>
> Now, library writters just need to modify their build system to take
> advantage of it, starting by the INRIA released libraries, especially
> the ones provided by the ocaml tarball directly like labltk.
>
> Friendly,
>
> Sven Luther
>
--shiv--

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[Stefano Zacchiroli]

On Wed, Mar 26, 2003 at 09:25:48AM +0100, Alessandro Baretta wrote:
> > I observed that both camlimages and labltk have a module 
> > Any idea how I can get both to co-exist? Thanks.
> This is a problem that comes up every so often: module 
> namespace cluttering. Some time ago I had pointed a name 

Yes, but the question was more specific: how can I have _camlimages_ and
_labltk_ coexist? IMO, it had nothing to do with a general namespace
cluttering problem.

So probably we need an answer from lablgtk and camlimages authors here.

Is it possible to change one (or both) of the modules' names?

Cheers.

-- 
Stefano Zacchiroli  -  Undergraduate Student of CS @ Uni. Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[Sven Luther]

On Wed, Mar 26, 2003 at 11:48:41AM +0100, Stefano Zacchiroli wrote:
> On Wed, Mar 26, 2003 at 09:25:48AM +0100, Alessandro Baretta wrote:
> > > I observed that both camlimages and labltk have a module 
> > > Any idea how I can get both to co-exist? Thanks.
> > This is a problem that comes up every so often: module 
> > namespace cluttering. Some time ago I had pointed a name 
> 
> Yes, but the question was more specific: how can I have _camlimages_ and
> _labltk_ coexist? IMO, it had nothing to do with a general namespace
> cluttering problem.
> 
> So probably we need an answer from lablgtk and camlimages authors here.
> 
> Is it possible to change one (or both) of the modules' names?

I don't understand what would be wrong with a Labltk.Image and a
Camlimage.Image ?

Friendly,

Sven Luther

-------------------
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

Re: [Caml-list] camlimages vs. labltk

[Stefano Zacchiroli]

On Wed, Mar 26, 2003 at 11:55:27AM +0100, Sven Luther wrote:
> I don't understand what would be wrong with a Labltk.Image and a
> Camlimage.Image ?

Nothing for me, but I'd like to hear that from upstream authors :-)

Cheers.

-- 
Stefano Zacchiroli  -  Undergraduate Student of CS @ Uni. Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney

-------------------
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