«

"Lex Spoon" <> schrieb im Newsbeitrag
news:...
> This thread has seemed to miss the biggest advantage of macros. Most
> examples so far are cases where the macro buys you faster code. This
> is not extremely exciting, IMHO, because a better compiler can often
> accomplish the things that are described. If you care that much about
> performance then surely you want to be using a good optimizing
> compiler, and a good compiler will surely know about, e.g., for loops
> that go across constant ranges. I tend to think of macros as bad
> style for this kind of thing, unless it's very clearly a performance
> problem you are having. Macros often look like functions, but they
> don't act like them, and it's very easy to introduce bugs with them.
>
> A much bigger advantage of macros is that you can literally extend
> the language. For example, it is nice to be able to type something
> like this:
>
> (regex (| h H) "ello, " (| w W) orld (? "!"))
>
>
> To allow this in the nicest way requires using a macro for 'regex.
> Without macros, you can still do it:
>
> (regex '(| h H) "ello, " (| w W) orld (? "!"))
>
> but now this guy is going to get compiled at runtime, and you get into
> the issue of trying to save the compiled regex somewhere ahead of
> time. And while regexes themselves compile pretty quickly, suppose
> it's something more like:
>
> (parser
> (grammer
> ;;... a BNF grammer ...
>
>
>
> I also loved the example of both printing a statement and executing
> it, which is extremely useful for assertion checking. You can't
> really do this properly without macros.

Just for the sake of my understanding: could one summarize this as "macros
make control of *when* something is evaluated easier"? I mean, marco
arguments are not evaluated before the macro "call" as opposed to function
arguments. With that, you can decide inside the macro, how you treat
those arguments and if you evaluate them at all. Thx!

Regards

robert

"Robert Klemme" <> writes:

> Just for the sake of my understanding: could one summarize this as "macros
> make control of *when* something is evaluated easier"?

More precisely: "macros make control of when, if, and how often,
something is evaluated _possible_."

Functions (your only other option) give you no choice.

But, yeah, you've got it.

--
It would be difficult to construe Larry Wall, in article
this as a feature. <>

"Robert Klemme" <> writes:
> Just for the sake of my understanding: could one summarize this as "macros
> make control of *when* something is evaluated easier"? I mean, marco
> arguments are not evaluated before the macro "call" as opposed to function
> arguments. With that, you can decide inside the macro, how you treat
> those arguments and if you evaluate them at all. Thx!


Yes, that's one big advantage. If you are willing to do everything at
runtime, then HOF plus a nice general syntax for literals
(e.g. s-expressions) give you the same thing.


-Lex

Alain Picard wrote:

> "Robert Klemme" <> writes:
>
>>Just for the sake of my understanding: could one summarize this as "macros
>>make control of *when* something is evaluated easier"?
>
> More precisely: "macros make control of when, if, and how often,
> something is evaluated _possible_."
>
> Functions (your only other option) give you no choice.

This statement is wrong if left in full generality: higher-order
functions can control quite precisely what gets evaluated when. If the
language offers both lazy and strict parameters, evaluation time control
extends to the parameter expressions as well.
It's a different kind of control than macros, of course. (It would be
interesting to see how things would map from macros to functions and
vice versa.)

Regards,
Jo

Joachim Durchholz <> writes:

> Alain Picard wrote:
>
>> More precisely: "macros make control of when, if, and how often,
>> something is evaluated _possible_." Functions
>> (your only other option) give you no choice.
>
> This statement is wrong if left in full generality: higher-order
> functions can control quite precisely what gets evaluated when. If the
> language offers both lazy and strict parameters, evaluation time
> control extends to the parameter expressions as well.

My apologies to the functional guys. I was responding from a lisp
newsgroup: so let me amend the above to end with "IN LISP".
[We do not have lazy evaluation by default.]

Alain Picard wrote:
> Joachim Durchholz <> writes:
>>Alain Picard wrote:
>>>More precisely: "macros make control of when, if, and how often,
>>> something is evaluated _possible_." Functions
>>>(your only other option) give you no choice.
>>
>>This statement is wrong if left in full generality: higher-order
>>functions can control quite precisely what gets evaluated when. If the
>>language offers both lazy and strict parameters, evaluation time
>>control extends to the parameter expressions as well.
>
> My apologies to the functional guys. I was responding from a lisp
> newsgroup:

Ah, the joys of inadvertent crossposting

> so let me amend the above to end with "IN LISP".

IIRC even Lisp allows you to keep expressions unevaluated via quoting.
So macros wouldn't be the only way to control evaluation: quote the
expression and have the callee evaluate it at a convenient time.

> [We do not have lazy evaluation by default.]

The default evaluation strategy doesn't change too much; all you need is
some way of deferred evaluation. It need not even be laziness, having a
meta level (such as quoting) or access to the compiler can be used.

As I said, it's still different from macros.

Regards,
Jo

Roman Belenov wrote:
> Joachim Durchholz <> writes:
>
>>IIRC even Lisp allows you to keep expressions unevaluated via
>>quoting. So macros wouldn't be the only way to control evaluation:
>>quote the expression and have the callee evaluate it at a convenient
>>time.
>
>
> The problem is that quoted form is just a piece of data from
> compiler's point of view, so it is kept as is and has to be interpeted
> in runtime (while code generated by macros is usually compiled
> normally);

If that's the case, it's probably more due to lack of demand than due to
serious technical issues.

> besides, such forms can not access lexical variables in the
> enclosing context (otherwise runtime environment would have to support
> access to lexicals by name, which has performance implications and is
> not necessary for normal compiled code). So, theoretically, you can
> use quoting to control the order of evaluation, but practically it
> will lead to very inefficient [code]

Agreed.

> and [quoting will lead to] less intuitive code.

Efficiency issues aside: how are macros more intuitive than quoting?

Regards,
Jo

Joachim Durchholz <> writes:

> IIRC even Lisp allows you to keep expressions unevaluated via
> quoting. So macros wouldn't be the only way to control evaluation:
> quote the expression and have the callee evaluate it at a convenient
> time.

The problem is that quoted form is just a piece of data from
compiler's point of view, so it is kept as is and has to be interpeted
in runtime (while code generated by macros is usually compiled
normally); besides, such forms can not access lexical variables in the
enclosing context (otherwise runtime environment would have to support
access to lexicals by name, which has performance implications and is
not necessary for normal compiled code). So, theoretically, you can
use quoting to control the order of evaluation, but practically it
will lead to very inefficient and less intuitive code.

--
With regards, Roman.

Standard disclaimer: I work for them, but I don't speak for them.

Joachim Durchholz <> writes:

> Efficiency issues aside: how are macros more intuitive than quoting?

Because they let you write what you intuitively expect (assuming your
intuitions are tuned a particular way, I suppose). In Common Lisp,
WHEN is a macro that lets you write this:

(when (> x y) (print x))

If you tried to write it as a function using quoting to prevent
evaluation you might try this:

(when (> x y) '(print x))

which won't work in general because of the iniability for the code
inside WHEN to evaluate the data '(print x) in the lexical environment
where it appears.

Or you could do this:

(when (> x y) #'(lambda () (print x)))

which could work but seems a bit convoluted (i.e. unintuitive)
compared to the macro version.

-Peter

--
Peter Seibel

Lisp is the red pill. -- John Fraser, comp.lang.lisp

Peter Seibel wrote:
> Joachim Durchholz <> writes:
>
>
>>Efficiency issues aside: how are macros more intuitive than quoting?
>
> Or you could do this:
>
> (when (> x y) #'(lambda () (print x)))
>
> which could work but seems a bit convoluted (i.e. unintuitive)
> compared to the macro version.

Um, right, but that's just a question of having the right syntactic sugar.

Regards,
Jo