ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Uther <>
Subject ANT semantics and power
Date Mon, 28 Feb 2000 20:12:35 GMT
Hi all,

  As has now been noted a couple of times, there are two issues here.  One
is ANT's basic semantics and the second is how powerful the language is


I think it is quite clear that ANT has a large procedural component: it
takes a sequence of tasks and execute()s them in a specific order.  It is
interesting because there are multiple orders depending upon the type of
task executed.  Assignment statements are executed first, and in a
different order to all other statements.

Consider the following build file:

<project name="Test" default="main" basedir=".">

  <target name="neverRun">
    <echo message="neverRun is running"/>
    <property name="hasRun" value="NeverRun has Run"/>

  <target name="main" depends="myInit">
    <echo message="main is running"/>
    <echo message="${hasRun}"/>
    <echo message="${inited}"/>

  <target name="myInit">
    <echo message="Init is running"/>
    <property name="inited" value="I've been inited"/>


When run through ANT this produces:

Init is running
main is running
NeverRun has Run

When I would expect (and get using Ludovic Claude's 'Big Change'):

Init is running
main is running
I've been inited

According to the properties at the time main is run, neverRun has been
executed and myInit has not.  This is exactly the opposite of what I would
expect given the dependancies and what has happened as far as the other
messages are concerned.

Ludovic Claude's 'Big Change' fixes this (as well as adding nested tasks,
but we'll get to that later).  It makes the property setting take place
just before execution and in a similar order to execution.  (I haven't gone
through the details of how he does this yet.  I think their may be neater
solutions than his current version, although it is certainly in the right

Another possible solution is to move all property setting out of the
targets.  This removes the expectation that it will be executed in 'target
order'.  I gather from one of the recent posts that this is the way things
once were and this might explain the current strange semantics.

Finally, you could go to a less procedural language.  This would be a major
change, but would help solve both this and the power problem.  The exact
spec of that language would need to be worked out.  As a starting point the
XML tags should be nouns, not verbs.
<> describes one more declarative
language (although not in much detail).

I see fixing this as more important than, and separate from, increasing
ANT's expressive power.  Currently the two detailed proposals about ways to
fix the semantics (mine and Ludovic Claude's) also add nested tasks, but
that need not be so.

Separate from <ForEach /> and the ability to add recursive tasks, do people
see changing the <property /> semantics in this way to be a good thing?


  I am intrigued by ANT being called a declarative language.
<> defines a
declarative language as follows:

> A general term for a relational language or a functional language, as
> opposed to an imperative language. Imperative (or procedural) languages
> specify explicit sequences of steps to follow to produce a result, while
> declarative languages describe relationships between variables in terms
> of functions or inference rules and the language executor (interpreter or
> compiler) applies some fixed algorithm to these relations to produce a
> result. The most common examples of declarative languages are logic
> programming languages such as Prolog and functional languages like
> Haskell.

There is also a second sense of the term 'declarative language' which the
above doesn't list.  That is that a declarative language should be simple
enough to be easily parsed and machine edited.  This is most easily defined
by example.  Postscipt is a turing complete language.  Noone uses it for
more than final output.  It is too flexible for arbitrary code to be read
in to an image editor and edited in a meaningful way.  PDF is a watered
down version of postscript that is used as a document transfer language
because it is simpler and easier to machine edit.

I suspect it is this second definition that you are using.  I.e. you don't
want ANT to become turing complete even if it is a functional language
because then it would become hard to machine edit.  Also, as I noted above,
ANT is already largely procedural, and so it is not declarative according
to the first definition.

If that is the case then I humbly submit that you've already gone too far.
ANT is already turing complete if people can define their own tasks.  (I
could define a few new tasks, namely fixedProperty, while and if.  By
defining createIf, createWhile and createFixedproperty these can already
take themselves as sub-tasks.  That's all I need.  It isn't very useful,
but it demonstrates the turing completeness.)

Given that, I think that staying at the current stage is not the best
choice.  Here are some options I think are better:

 - Allow nested tasks, but wash your hands of responsibility for making
them editor compatible.  I think you're going to need to do the
hand-washing anyway, just for the current level of nesting.

 - As above, but introduce a few very clearly defined nestable tasks into
the standard collection of tasks.

 - Reduce the power of ANT's language so it is no longer possible to use
nested elements.  (also, see above for the possibility of moving to a truly
declarative language.)

Finally, someone asked for examples of where nested tasks might be useful
and I've already given some.  e.g. the switch task.  Here they are again.

I would like to be able to handle different operating systems.  Java is not
completely cross-platform, although it is close.  Being able to specify
those last few bits in a build-file is very useful.

<switch name="os.type">
	<case value="Mac OS">
		<javac source="**/platform/mac/**">
	<case value="Win*">
		<javac source="**/platform/win/**">
	<default> <!-- assume UNIX -->
		<javac source="**/platform/unix/**">

The examples for ForEach mostly fall into categories where a more complex
task would do.  For instance, as I've already mentioned, I'd like something
of this form:

<ForEach variable="i" dir="domains"> <!-- for each file in the dir
'domains' -->
	<ant dir="i"/>

Yes, this could be done by making the <ant /> task more powerful.  I don't
see why forcing the complexity into every single task is a win.

I'd now like to turn this question around.  What sort of machine processing
do you have, or forsee, that this breaks AND that isn't already broken?  A
simple graphical editor that just allows you to add tasks and fill in
attributes works just as well with these new tasks as with the old system.

As I said, I consider the nested tasks a much less important change than
fixing the semantics.  I also consider it a much smaller change, but there
seems to be some disagreement on that point.


\x/ill            :-}

View raw message