macros and is parsed

[Abhijit A. Mahabal]

In E6 Damien writes about macros:

"As soon as it has parsed that subroutine call (including its argument
list) it will detect that the subroutine &request is actually a macro, so
it will immidiately call &request with the specified arguments".

If macroness is found *after* parsing the arguments, when does the "is
parsed" trait's action kick in?

Elsewhere, he writes:
"The 'is parsed' trait tells the parser what to look for immediately
after it encounters a macro's name".

I would guess that the latter is what is intended. Or is it that the
absence of an explicit "is parsed" changes the behaviour (for efficiency
reasons, perhaps, as many common uses will parse arguments in standard
ways [though act in mind warping ways] ) ?

abhi.

Abhijit A. Mahabal http://cs.indiana.edu/~amahabal/

[Austin Hastings]

You're both right.

Notice that "request" does not have an "is parsed" tag. So the default
behavior for macro calls is to use the parsing syntax of subroutines
(which makes a lot of sense).

Thus, the call to result "looks like a subroutine call" (because that's
the default way to invoke a macro) but is recognized, after parsing, as
a macro (because that's how it's implemented -- parse a rule, follow
the results).

What's unclear to me is the behavior as specified -- Ex6 calls for the
C<is parsed> syntax to specify the argument parsing. I had thought that
an infix or postfix macro would be possible because the macro would
have access to the parser internals. How to do that is missing.

E6> The is parsed trait tells the parser what to look for immediately
E6> after it encounters the macro's name.

=Austin

[Larry Wall]

On Sat, Aug 02, 2003 at 08:40:26AM -0700, Austin Hastings wrote:
: You're both right.

Well, actually, I think Damian misspoke slightly. I only aim for
95% accuracy in the Apocalypses (or I'd never get them done). So I
think it's pretty spectacular if Damian gets to 99.44% accuracy in
the Exegeses.

: Notice that "request" does not have an "is parsed" tag. So the default

: behavior for macro calls is to use the parsing syntax of subroutines
: (which makes a lot of sense).
:
: Thus, the call to result "looks like a subroutine call" (because that's
: the default way to invoke a macro) but is recognized, after parsing, as
: a macro (because that's how it's implemented -- parse a rule, follow
: the results).

I suspect a macro is always recognized the moment its name is parsed,
whether or not there is an "is parsed". The trait merely overrides the
default parse of the macro.

: What's unclear to me is the behavior as specified -- Ex6 calls for the

: C<is parsed> syntax to specify the argument parsing. I had thought that
: an infix or postfix macro would be possible because the macro would
: have access to the parser internals. How to do that is missing.

It is possible, but an infix or postfix macro may only take a standard
expression on the left, since that part has already been parsed.
The macro could give that expression non-standard semantics, however.
And an infix operator can specify an "is parsed" for its right
argument. In fact, ??:: could be implemented as an infix:?? macro
that does a special parse looking for a subsequent :: token.

Larry

[Brent Dax]

Larry Wall:

> argument. In fact, ??:: could be implemented as an infix:?? macro
> that does a special parse looking for a subsequent :: token.

...which gives us another built-in's implementation.

macro infix:?? ($cond, $expr1, $expr2)
is parsed(/:w (<Perl6.expr>) <'::'> (<Perl6.expr>)/) {
return {
if($cond) {
$expr1; #Last expression is the return value, right?
}
else {
$expr2;
}
};
}

Thanks, Larry!

--Brent Dax <br...@brentdax.com>
Perl and Parrot hacker

[Larry Wall]

On Sun, Aug 03, 2003 at 02:05:50PM -0400, Brent Dax wrote:
: Larry Wall:

: > argument. In fact, ??:: could be implemented as an infix:?? macro
: > that does a special parse looking for a subsequent :: token.
:
: ...which gives us another built-in's implementation.
:
: macro infix:?? ($cond, $expr1, $expr2)
: is parsed(/:w (<Perl6.expr>) <'::'> (<Perl6.expr>)/) {
: return {
: if($cond) {
: $expr1; #Last expression is the return value, right?
: }
: else {
: $expr2;
: }
: };
: }
:
: Thanks, Larry!

Well, it's not quite so simple. You have to worry about precedence
in the subexpressions, and you have to make "my" in the subexpressions
leak out of the inner blocks. Both of these are generic issues,
of course, and probably need more general solutions.

Larry