ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Problem using script task
Date Sun, 07 Jan 2001 07:29:53 GMT
At 12:40  7/1/01 -0500, Jason Rosenberg wrote:
>> At 07:44  28/12/00 -0500, Jason Rosenberg wrote:
>> >Ant is a scripting language.  The idea of using a <script> task is a bit
>> >nonsensical.  Just extend the Ant Scripting language to do the simple
>> >things we need (there are not too many of these).
>> 
>> ummmmmmmmm .....
>> 
>> Ant is supposed to be a ***declarative*** scripting language. 
>
>Not really, there are lots of built in procedural tasks, which are
>part of the core (javac,mail,fail,etc.).  Actually, I think all the tasks
>are procedural.  That is, they execute actions at the time they
>are 'called'.  Even the <property> task behaves this way.  Nothing
>'declarative' about tasks in Ant.

welll - these are procedural tasks yes but that doesn't have anything to do
with the representation which is/should be declarative. 

>Sounds like the old "Lisp is great, its declarative, but umm, could we
>please have some loops and conditional execution added" reducto ad absurdum.
>Lisp was worthless until looping and flow control was added, but then
>the whole elegance of the declarative principal was lost.
>
>There is no such thing as an adequate declarative programming
>construct.

sure there is. There is a whole bunch of em actually. Look to many
data-representation programming constructs, SQL constructs, some XML
constructs .... but right - they must be failures ?

>Yes, agreed, templates are the crux of the problem, and antcall is a hack,
indeed.
>But, what is a template.  It's a reusable task.  One that can be recalled
and reused
>with different parameters.   Can you say "sub-routine"?

yes ..... but I am not sure you understand what declarative means. It
refers to representation and not features. Declarative constructs can still
have selection, limited iteration, sequence and reusable blocks but it is
how they are repsented that differs from procedural programming.

>> What you seem to want is a ***procedural*** language which I am definetly
>> -1 for a whole bunch of reasons that have been enumerated in the past.
>> 
>Ant is procedural, and that is what I want.  It is close to being useful,
>to date, but just needs to add a very small set of features to close the
>case.  Simply admitting that it is procedural would really clear the way.
>Let's stop beating around the bush.

There are some procedural bits in it but I think they will be removed if
they are essential parts of ant (ie the ant-call functionality). Other
tasks may be left that allow you to do procedural stuff (ie MT stuff talked
about recently) but I will fight tooth and claw to prevent core becoming
procedural.

Luckily for you Ant2.0 will most likely have reusable bits so you can
reimplement it any way you want. There has been one person who has
approached me to use Ant2.0 as a general scripting interface (ie
procedural) for their project (a java based desktop environment) and I know
of two other xml-procedural scripting initiatives (xmlshell and another).
So feel free to add the functionality you want - I think the core will be
flexable enough for that (I hope it will). 

But don't expect the default ant build representation to become procedural.

>> <target name="foo" condition="a ^ ~(b == (c&d|e^f) ) &d" />
>> 
>> and trying to work out what that means.
>> 
>
>Yes, I think the beauty of Ant is that it has the power to keep
>things simple and human readable.  I like the <execute-task>
>idea mentioned by someone on another topic, or possibly a 
>simple case:
>
><case property="caseProperty">
>    <if value="1" execute="doMainCompile"/>
>    <if value="2" execute="doPartialBuild"/>
>    <default execute="showErrorAndFaile"/>
></case>

these sorts of things are possible in future but we won't know yet. I used
to be in favour of xslt-like preprocessing for templating but that can only
represent structural constraints (ie static) while some people have
demanded dynamic templating like above (and like what ant-call satisfies).
Difficult to say how it will be satisfied atm till we have a play.

>> >Some fundamental "task" issues are:
>> >
>> >    if-then-else
>> >    switch
>> >    loop
>> 
>> not a chance of making core. If you want it then create your own tasks.
>> Look to ant-dev archives for reasoning.
>> 
>
>Not sure there is much reasoning to look for.  You seem to be saying
>that the pristine declarative nature should be the primary consideration,
>and yet, repeatedly, the core has been augmented by lots of absolutely
>necessary procedural constructs, both in terms of the core builtin
>tasks, and the "depends","if","unless", etc......

arguing from ignorance love that approah. There is reason if you care to read.

>I think there are enough people now who see the shortcomings of your
>historical reasoning that I would really doubt you are correct in saying
>"not a chance of making core"....

It is not my reasoning as such. I was just a user when most of the
"discussion" was going down and ignored it for most purposes. I think
Duncan was around then and maybe Sam Ruby but other than that there has
been a full refresh of the guards so no one else was involved I don't
think. If you want details look in the archives.

You are free to develope any tasks you want thou - some of the active
developers on ant-dev have case/if tasks to suit their needs and you will
be easily able to do the same. However it is unlikely that the nature of
the tool will change as much as you want it to so if you want procedural
elements that can not be represented at task level feel free to fork. Thats
the beauty of OSS - you scratch what itches.



Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Mime
View raw message