Browse thread
[Caml-list] Announcing the OMake build system version 0.9.1
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2004-09-06 (15:51) |
From: | skaller <skaller@u...> |
Subject: | Re: [Caml-list] Announcing the OMake build system version 0.9.1 |
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