Re: [Caml-list] camlimages vs. labltk

[Sven Luther <luther@dpt-info.u-strasbg.fr>]

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