From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id UAA22521; Thu, 21 Mar 2002 20:26:27 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id UAA21770 for ; Thu, 21 Mar 2002 20:26:26 +0100 (MET) Received: from c007.snv.cp.net (c007-h000.c007.snv.cp.net [209.228.33.206]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id g2LJQPX22388 for ; Thu, 21 Mar 2002 20:26:25 +0100 (MET) Received: (cpmta 5958 invoked from network); 21 Mar 2002 11:26:19 -0800 Received: from 65.187.194.217 (HELO vaiobambino) by smtp.directvinternet.com (209.228.33.206) with SMTP; 21 Mar 2002 11:26:19 -0800 X-Sent: 21 Mar 2002 19:26:19 GMT From: "Jeff Henrikson" To: "Xavier Leroy" Cc: Subject: RE: [Caml-list] The DLL-hell of O'Caml Date: Thu, 21 Mar 2002 14:43:13 -0500 Message-ID: <003501c1d110$a357b280$0b01a8c0@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20020321191028.A18937@pauillac.inria.fr> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > You're confusing whole programs with libraries. > A program can be > distributed as a statically-linked executable . . . Ideally, I'd like to confuse them as much as possible. From the libtool manual: "libraries are programs with multiple entry points, and more formally defined interfaces." I think a good rule of thumb for a rational developer prospectively looking at using a new language is "How easy is compared to C?" Insert your favorite term [package management/system integration/dynamic library futzing]. I claim our choice in package management should make sense to a good but non-ocaml-indoctrinated programmer. Right now I don't think the proposals fall along those lines. Ideally, multiple ocaml libraries loaded into the same process could do all the same things as C: - share (ocaml) runtimes - call each other - be loaded and unloaded - call and be called by other languages without much programmer effort and at build time: - if no interfaces are changed rebuild only one shared lib and rebuild only that. (In fact newer Linux can even reload such a recompiled lib while the process is still running, hence you can upgrade libc while still running, etc.) Currently, certain tools to make this so are missing. (For example both forward and reverse stub generators smarter than camlidl and camoflage.) But we should not make package management design choices that preclude these possibilities unless there's a good reason to. > This is a strawman argument in many respects: > > - The OCaml distribution is 100 KLOC and recompiles in a few minutes > on a 1000 EUR machine. So, 2MLOC takes less than one hour, not two > days. . . . I am admittedly offering arbitrary unchecked numbers. But I don't think the argument changes, it's analagous to an order of growth argument. If build times don't matter, then why does "make" exist? I for one am quite impatient to build caml on MPW with a broken make tool (or makefiles? I haven't quite taken the time to understand.) which recompile the world upon one file touch. I heard Gerry Sussman (scheme coinventor) quip something once along the lines of "Software is like some funny kind of gas. It takes up all the space you give it." I think this applies to build times as well as run times. > > To change the subject slightly, there seem to > be some other > > dangerous related "purity before progress" idea bugs > > floating around, like > > And there seems to be some dangerous "let's hack > something before > thinking over the consequences" ideas in your message. Admittedly. I would probably think differently if I everything were up to me, but since I know there are enough people of the opposite thinking to keep me in check, I feel it's most useful for me to err on this side. In groups with abundance of hacker mentality I am quite happy to play the other role. Sorry if anyone is offended. Regards, Jeff Henrikson ------------------- 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