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
