=> On Thu, 7 Jun 2001 06:08:46 -0700 (PDT), Roger Vaughn <[EMAIL PROTECTED]> said:
> And as we well know from experience with other languages, sequences of > operations frequently need iteration and conditional execution. That is, > unless you want to model the language after Prolog, etc. ;-) We could be functional, without being an inference engine. ;) I think that declarative syntax is a big win. Iteration is expressable a la the poor maligned XSLT. We can iterate under the covers, but there's no reason to permit the buildfile writer to express them explicitly. Think MAKE; You express transformations and 'iterate' by implication when foo depends on foo.o, bar.o, and baz.o. The syntactic difference in ANT, from my possibly ignorant perspective, is that you conventionally express dependencies between tasks, not between software products. Our iteration is under the covers (IMHO) for only one reason: javac does it. This permits us to shove under the covers much of the complexity explicitly expressed in MAKE. This is shift is necessary: We'd all die of old age before completing any project if we had to run a separate instance of javac for each .java -> .class transformation we wanted to do. To accomplish the goals you desire, we could permit the expression of the make-like .java.class recipie, and some sort of inverted up-to-date target, which asserts that for each .foo in <source> there should be a .bar in <dest>, which should be up-to-date, otherwise run whatever-thingy on the individual .foo file. This idiom would permit the expression of some heinously bad java compilation targets. It would also permit the expression of the ideas the iterator-boosters desire. If this is already-discussed-and-discarded, or blatantly-obvious-and-agreed-on, I'll just blush and shut up for a somewhat longer time again. ;) - Allen S. Rout
