macros and is parsed
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. Mahabalhttp://cs.indiana.edu/~amahabal/
Re: macros and is parsed
--- "Abhijit A. Mahabal" <[EMAIL PROTECTED]> wrote: > 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] ) ? 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 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
Re: macros and is parsed
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 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
Re: macros and is parsed
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 () <'::'> ()/) { return { if($cond) { $expr1; #Last expression is the return value, right? } else { $expr2; } }; } Thanks, Larry! --Brent Dax <[EMAIL PROTECTED]> Perl and Parrot hacker
Re: macros and is parsed
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 () <'::'> ()/) { : 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