Dave Whipp wrote: > (OK, thats not a good example, but you get the gist). If sure it would > be possible to write the macro in such a way that it looks at its LHS > arg -- and ignores itself if its not a Database object ... but that > places an overly large burden on the macro writer. To avoid this burden, > I'd like to propose C<macromethod> as a counterpart to C<submethod>. A > macromethod would enable me to write an invocant-scoped macro, without > polluting the lexical namespace: > > class Database > { > ... > macromethod select ($lhs, $rhs:) is parsed /<sql.select.body>/ > { > "$lhs.do_sql('select $rhs')" > } > } > > Without this mechanism, then we need a way to prevent an infinite > regress on macro processing. I am assuming that, if the output of a > macro is a string, then that string will be re-parsed and any macros in > it will be expanded. How would an infix macro indicate that it didn't > want to handle the "$io.select" example? If it returns its input, > unchanged, then that would be an infinite loop.
Well, if you did that, it surely couldn't be polymorphic, which kind of defeats most of the purpose of making it a method. Yeah, namespace pollution is a little issue, but not really. You could scope the macro to the Database class, so it would be C<Database::select ...>. Interestingly, it would be almost impossible to get effective methods that use an C<is parsed> trait. Is it legal to do so? Luke