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 RAA18528; Mon, 6 Sep 2004 17:51:30 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA19295 for ; Mon, 6 Sep 2004 17:51:29 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i86FpRXH011365 for ; Mon, 6 Sep 2004 17:51:28 +0200 Received: from [192.168.1.200] (ppp210-32.lns2.syd3.internode.on.net [203.122.210.32]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i86FpN4Y047198; Tue, 7 Sep 2004 01:21:25 +0930 (CST) Subject: Re: [Caml-list] Announcing the OMake build system version 0.9.1 From: skaller Reply-To: skaller@users.sourceforge.net To: Andreas Rossberg Cc: caml-list In-Reply-To: <413C4277.9000700@ps.uni-sb.de> References: <4139ECD3.1050708@cs.caltech.edu> <001e01c492a6$872c7280$19b0e152@warp> <413A0921.7030607@ntlworld.com> <413A1E89.10806@libertysurf.fr> <1094361655.3352.476.camel@pelican.wigram> <87hdqc3kfr.fsf@qrnik.zagroda> <1094396893.3352.635.camel@pelican.wigram> <20040905160936.GB29119@old.davidb.org> <1094409059.3352.838.camel@pelican.wigram> <413C4277.9000700@ps.uni-sb.de> Content-Type: text/plain Message-Id: <1094485883.3352.1122.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 07 Sep 2004 01:51:23 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 413C877F.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 rossberg:01 fixpoint:01 fixpoint:01 outputs:01 interscript:01 python:01 optimise:01 declarative:01 iterative:01 recursion:01 generality:01 declarative:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 2004-09-06 at 20:56, Andreas Rossberg wrote: > skaller wrote: > >> > >>>Fixpoint iteration works and is universal. > >> > >>It isn't universal, though. There are pathalogical cases, even with common > >>tools where it never will stabilize. > > > > I think it is very rare to find a case which would > > stabilise with a manual order and not fixpoint iteration. > > That isn't the point, though. There are tools that are not intended to > produce stable outputs! For example, a tool might be generating time > stamps or guids in its output files. Such tools will never work with a > fixpoint scheme, so you can hardly claim its universality. Yes that's true. So in fact the claim must be watered down. Perhaps you can help characterize the actual properties the system has? One needs to observe that a conventional build will also yield indeterminate results, if, for example, you encode the build time into the result -- build it again, you get a different timestamp. Where such artefacts are intended, you can modify the build specification to exclude this information from consideration as an output for the purposes of convergence checking. Interscript can handle this (you can just use the ordinary Python open() function instead of the special one :) So yes -- more work is needed to characterize what can and can't be done, and even more to figure out how to optimise the process. > Also, I'm not convinced that the move from a declarative to an > imperative build paradigm is really what most people into functional > programming would like to see... ;-) Well, the key concept is of finding a fixpoint, which is central to functional programming. The iterative algorithm for doing it is nothing but tail recursion.. :) The fact that the build rules are 'executable' is to obtain generality and is the same as for make. The thing is that functional programming is NOT declarative. Perhaps if there were a more universal and efficient way to specify how to compute a value, there could be, but so long as one is encoding functions the way we do in C, C++, Ocaml, and many other similar languages I can't conceive of it as 'declarative' programming -- the typing is declarative, and perhaps Mercury is declarative -- ML function codes certainly aren't. I hinted at a way to structure the build rules more declaratively using a graph generating a category -- but the fact is I don't really have more than a hint how this might work. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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