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