>>>>> "RK" == Rob Kinyon <[EMAIL PROTECTED]> writes:
>> > Text-substitution macros would have to be handled in an earlier pass, >> >> I still don't see evidence for this. Or maybe I do, but I don't see >> any reason that the preprocessing pass must finish before the parsing >> begins. RK> Mixing C and Perl ... RK> my $foo; RK> BEGIN { $foo = '}'; } RK> #define OPEN { RK> #define CLOSE $foo RK> void main (void) RK> OPEN RK> BEGIN { $foo = '{''; } RK> printf( "I don't work\n" ); RK> CLOSE RK> How does that work out? The issue is that you can interrupt the RK> parsing process with executable code that can affect the parsing. RK> That's a good thing. It doesn't work so well with text-substitution, RK> though. Hence, I would argue it should be disallowed. from S06: Macros (keyword: macro) are routines whose calls execute as soon as they are parsed (i.e. at compile-time). Macros may return another source code string or a parse-tree. i see uses for text macros. sure they can trip you up but that is going to be true about AST macros as well. macros are inherently trickier than plain coding as you are dealing with another level at the same time. so the author of your bad example should learn how to do that correctly and not expect perfect DWIMMERY with an advanced technology. and that excerpt also means that p6 macros are not done in a preprocessing pass but at normal compile time as soon as the macro call is fully parsed. so a text returning macro would run and the compiler will replace the text of the parsed macro call and start reparsing with the returned text. there may be some juggling of the main parse tree to deal with this but it can be done without going too insane. :) uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org