From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA02968 for caml-redistribution; Wed, 17 Sep 1997 10:33:45 +0200 (MET DST) 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 RAA27697 for ; Tue, 16 Sep 1997 17:38:11 +0200 (MET DST) Received: from kronstadt.rahul.net (kronstadt.rahul.net [204.95.70.128]) by nez-perce.inria.fr (8.8.7/8.8.5) with ESMTP id RAA22122 for ; Tue, 16 Sep 1997 17:37:41 +0200 (MET DST) Received: (from itz@localhost) by kronstadt.rahul.net (8.8.5/8.8.5) id IAA10793; Tue, 16 Sep 1997 08:36:11 -0700 Date: Tue, 16 Sep 1997 08:36:11 -0700 Message-Id: <199709161536.IAA10793@kronstadt.rahul.net> From: Ian T Zimmerman To: caml-list@inria.fr In-reply-to: <6086.199709131752@venus> (message from William Chesters on Sat, 13 Sep 1997 18:52:43 +0100) Subject: Re: ocaml: demand-driven compilation? Sender: weis In message <6086.199709131752@venus> (message from William Chesters on Sat, 13 Sep 1997 18:52:43 +0100), you write: > Are there plans to extend the separate compilation system of ocaml > to take over some of the functions of make, as the Java compiler > does? The Java compiler not only checks sources against the > precompiled signatures of the modules it refers to, as > ocamlc/ocamlopt do; it also checks the existence and modtime of the > bytecode file against the source and (re)compiles if necessary. > With a little hack to get any necessary standard libraries included > in the link command automagically, we wouldn't need makefiles at > all. For me it would even be nice to able to specify the C files > implementing the external functions needed by each source _in the > source itself_. IMO things like this don't belong to the language or compiler. It is a _disadvantage_ of Java that it tries to be a `complete environment', and I bet the reasons why it is packaged that way has a lot to do with marketing b*s*t. Apart from the general reasons of going against the toolkit philosophy (if you try to have a program do too much, it stops cooperating nicely with the rest of the system), in a compiler there's another reason: depending on the file system in nontrivial ways would make it harder or impossible to verify that the language has a sound semantics and that the compiler implements the semantics correctly. > It would also be possible to do it (approximately) without touching > the compiler, say using ocamldep, but it would get messy. Yes, it would definitely be possible to beef up ocamldep. The result would be a reimplementation of make in ocaml. Why reinvent the wheel? And why do you dislike makefiles anyways? They are the right tool for the job. Just my penny worth. -- Ian T Zimmerman The dilemma is that when you model something completely on efficiency, a lot of people get hurt. Dr. Leonard Duhl of UC Berkeley, discussing `managed medical care'.