Different people understand different things under MACRO. But I'd say to
anybody who's familiar with Lisp, this is certainly has MACRO like
semantics. The difference would be that in Lisp you explicitly (using
"quote") have to tell the evalutor not to evaluate an expression in a macro
definition. E.g.
(defmacro Square (X) '(* ,X ,X))
which is equivalent to:
(defmacro Square (X) (quote (* ,X ,X)))
would have to desired effect. But as macros are expanded at compiler
pre-processor time the following definition would not work for the general
case:
(defmacro Square (X) (* ,X ,X))
For more on macros in Common Lisp take a look at these notes:
http://www.apl.jhu.edu/~hall/Lisp-Notes/Macros.html.
--
knut
> Well, I must be stupid then... Unlike you, I don't consider <macrodef> a
> MACRO at all. It has nothing to do with *textual* replacement. The
> non-existent <include>, and XML entity includes *are* textual replacement.
> <macrodef> certainly is NOT. <macrodef> is a TASK, which happens to define
> and the same time it implement a(nother) new TASK, using Ant's native XML
> syntax rather than Java code. It could as much be called <taskimpl>, and
the
> feeble link to MACRO would then be even more tenuous that it already is!
>
> It turns out that when you write the implementation of that new task, you
> *ARE* using Ant's syntax to 'code' it, and thus Ant normal behavior of
> expanding properties *AS USUAL* should be respected.
>
> It's a huge leap to say the least to consider <macrodef> defining a
textual
> MACRO. I myself am very aware of Ant's introspection and property
expansion
> rules, which is why I *expect* them to be applied everywhere in Ant.
>
> So I repeat: I'm -1 to <macrodef> with non-standard expansion of Ant
> properties. This is non-bidding of course, as I am not a committer... --DD
>
> > -----Original Message-----
> > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, August 20, 2003 7:34 AM
> > To: Ant Developers List
> > Subject: RE: [new tasks] presetdef and macrodef
> >
> > Dominique,
> >
> > As its name indicates <macrodef/> is a MACRO. And macros are macros are
> > macros
> > and they are suppose to be textually replaces at the point on
> > invocation.
> > So the fact that properties are substituted at the expansion point is
> > what anyone understanding that it is a MACRO would expect.
> >
> > My point with allowing for a way to expand inline, (which I am not even
> > sure
> > gives any advantage, since properties are inmutable) is trying to
> > address
> > the fact that in many MACRO languages there is some way to evaluate some
> > things
> > at definition time and fix the value then. some sort of eval.
> >
> > Maybe one can acomplish this with some sort of property interceptor: So
> > a syntax like:
> >
> > ${macroinline:x} will cause the property "x" to be substituted
> > at definition time
> > while ${x} will get substituted at expansion time.
> >
> >
> > > -----Original Message-----
> > > From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> > > Sent: 19 August 2003 21:24
> > > To: 'Ant Developers List'
> > > Subject: RE: [new tasks] presetdef and macrodef
> > >
> > >
> > > > -----Original Message-----
> > > > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> > > > Sent: Tuesday, August 19, 2003 12:47 PM
> > > > To: Ant Developers List
> > > > Subject: RE: [new tasks] presetdef and macrodef
> > > >
> > > > > What I am saying is that even with a different notation for
> > > > > attributes, normal property resolution will take place in the
> > > > > context of the user of the macro, and not when the macro
> > > is defined.
> > > > > This is a consequence of the way <macrodef/> is implemented, in
> > > > > particualar to support embedded elements.
> > > > >
> > > >
> > > > Now that you explained this, I would really like to have a way of
> > > > defining properties that are expanded at definition time. I do not
> > > > know if it can be done with the syntax we already have or we need
> > > > something diferent. Probably we do, since we would need a way to
> > > > distinguish between inlined (replace during definition) and not
> > > > inlined (replaced during evaluation) properties.
> > >
> > > I stopped arguing this point, as I was the only one concerned
> > > apparently, but since Jose Alberto brings it up again...
> > >
> > > Having ${NAME} not evaluate to the value, if any, of the NAME
> > > property, at the time the task it's used in (<macrodef> is
> > > this case) is executed, is REALLY REALLY BAD in my sincere
> > > opinion. Maybe <foreach> does it, but that doesn't make it
> > > any better. Properties should *always* be evaluated at the
> > > place where they are defined.
> > >
> > > If I'm not mistaken, and ${NAME} is evaluated as the time the
> > > defined Macro is used, rather than defined, then is becomes
> > > some kind of implicit attribute of that Macro, and it's much
> > > better to explicitly define it as an attribute.
> > >
> > > OTOH, if it behaves 'normally', as in what Ant does today, it
> > > is simply a way to customize the way the macro itself (its
> > > implementation if you will).
> > >
> > > It seems that so far, my point has either not been well
> > > understood, or dismissed (which is troubling to me, given the
> > > huge confusion that would result IMHO). --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
