Re: [Caml-list] GODI (was: CTAN/CPAN for Caml (COCAN ...?))

[james woodyatt <jhw@wetware.com>]

On Monday, Jul 21, 2003, at 09:32 US/Pacific, Richard Jones wrote:
>
> There are two big lessons from Java about how NOT to do this:
> Actually, THREE big lessons about how NOT to do this:
>
> (1) $CLASSPATH

Yeah, the mistake here is that a resource *identifier* is not the same 
as a resource *locator*.  I'm less worried about the process the INRIA 
tools implement to locate .cmo and .cmi files than I am about the 
semantics the Ocaml language supports for identifying libraries under a 
federated naming authority.

The issue at hand-- for me, at least, as a guy writing a component 
toolkit-- is the anarchy caused by planting the root of the 
extended-module-path production in a single global namespace with no 
organization.  I can enjoy the occasional visits to anarchy: I've been 
to Burning Man more than once.  But I like to live and work in 
republics-- especially in republics where the citizens can afford their 
upkeep (but that's another rant).

> (2) uk.co.mycompany.unweildy.modules.names

Yeah again.  The problem here is the conflation of the module path with 
the naming authority.  When you want to use modules from multiple 
libraries with different naming authorities, you need a way to identify 
the library resource that contains the extended module path.  That's 
why we can't do it with just compiler and linker arguments.  We need 
new syntax.

Right now, there is one library that contains all extended module 
paths: the Standard Objective Caml library.  (Note well: I am not 
talking about a .cma file here.)

On my system, the contents of that library are located in 
<file:///usr/lib/ocaml/>.  Since there's only one library, I don't have 
to identify it explicitly in my code.  The locator is hard-coded into 
the compiler and linker.  I can use arguments/environment to change it, 
and even add multiple locators to search, but I can't change the fact 
that there is only one library that must contain all the extended 
module paths in my system.

Which wouldn't be so bad-- if there were an omniscient, omnipotent, 
omnibenevolent worldwide librarian to regulate top-level module name 
assignment.  There isn't one, and I'm pretty sure I don't want one.

> (3) ant

Yeah again again.  Don't get me wrong: I hate /usr/bin/make more than 
any of three of you.  But I don't regard 'ant' as an improvement.  That 
said, the topic of software construction tools is completely unrelated 
to the main issue that fished me out of lurk mode: the opportunity to 
agitate for multiple roots for extended-module-path and a federating 
naming authority for those roots.


-- 
j h woodyatt <jhw@wetware.com>
that's my village calling... no doubt, they want their idiot back.

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