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] Completeness of "Unix" run-time library
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-03-18 (21:16)
From: Kenneth Knowles <kknowles@b...>
Subject: Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

On Thu, Mar 18, 2004 at 10:57:23AM -0800, Shawn Wagner wrote:
> On Thu, Mar 18, 2004 at 01:56:38AM -0700, Matt Gushee wrote:
> Even if one of us did change the name of ours, there would still be problems
> if someone wanted to use both, because some modules have the same names.
> I've also noticed other libraries recently where that sort of colllision
> would be a problem. As the available number of libraries for ocaml grows,
> it'll get worse. High on my wish-list for the core ocaml system is
> namespaces or something similiar to help resolve this problem.

I was just thinking about this today on the train... The thing that solves it
for perl is for modules to appear to be inside each other even though they are
developed/installed separately.  I agree that the ocaml syntax already gives
more sugar and different ways of doing things than is really necessary, so I
really feel namespaces and modules would be redundant.

For ocaml, since modules are not first-class, wouldn't it just be a compilation
frontend issue to do this merging (in addition to some syntax to declare module
X.Y)?  I'm just pondering, but it seems possible and remarkably useful in order
to move towards a CPAN-like module repository.  Dependencies between modules
would naturally cause compile-time failure if they were not present, which is
desirable.  This seems like one simple step which would enormously increase the
ability of the community to more effectively contribute libraries and modules,
and halt a lot of complaints to the INRIA team.

On the bright side, at least the collisions are only at the module level... if
each library contained all modules in a larger module, such as with the -pack
option, then only this outer name need be unique.


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