English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

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: 2003-03-26 (11:39)
From: Sven Luther <luther@d...>
Subject: Re: [Caml-list] camlimages vs. labltk
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.


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