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