I searched the archives with Google (what, no internal search engine??), and found the thread on perl6 macros, which I did read.
>From what I saw, it mostly concentrated on using macros for speed. That should be a minor argument, especially considering this is perl. :) Common Lisp macros are incredibly powerful. I remember hearing about their power, and no one being able to explain the power to me. Then I read On Lisp, which is a great book which has since been put online: http://www.paulgraham.com/onlisp.html (I'm only 100-odd pages through, and I've found it extremely enlightening.) Basically, here's the really quick overview. Lisp code is made out of lists. The entire tree of code is basically lists of lists in the appropriate places. A macro receives its arguments *as* unevaluated lists. The macro is compiled at compiletime, and then is executed at compiletime for each time that it is used in the code. The macro is essentially a transformer that transforms given code as input, to a different set of code for output, at compiletime, with the full power of lisp. The resulting code is then inlined. This gives the macro the ability to get at the calling enviornment, meaning that the one reason (or so I was told) we need the 'calling environment' for Perl6 subs could instead use macros, and allow Dan to make the internals that much faster, since he has more freedom. This is something that I'd *really* like to see in Perl 6. Instead of receiving each argument to the macro as a list-based concrete syntax tree, it would instead receive a Perl-ish version of it, whatever that means. Hashes, arrays, etc would form the internal tree of the CST/AST. This also plays into allowing Perl to generate these CST/ASTs from within Perl, but that's a different discussion. The syntax should be simple enough that the CST/ASTs can be writeable. Lisp handled this by making the language syntax hard enough that the CST is just as easy as the language. :) Other things that are useful for macros is the ` and , and ,@ operators. These essentially are quoting operators. Any instance of , inside a `() is interpolated. This sounds similar to double-quotes, but the essential difference is that double-quotes require you to escape the things you don't want interpolated, whereas the backtick `() operator requires you to escape the things you *do* want interpolated. Writing macros to return a eval-block 'object' would be the most Perlish way, imho. You'd just need a way to interpolate the results of other eval-blocks objects or or variables into an eval-block, with some form of syntax. The only problem with them is that eval blocks have the lexical scoping, while the backtick operator provides raw code which gets interpolated at the call-site, and gets its lexical scoping *there*. Finally, calling syntax. I think macros should have the same syntax as subroutines. If I find a function is too slow, I could always macro-ize it and not have to change any of the calling code. (If we allow for inlining of functions, then this particular use of macros disappears.) The big difference between macros and inline functions in Lisp is that a macro isn't a function, can't be put into a variable, referenced, called dynamically, etc...it is a compile-time only object. They each have their uses they are best-suited for. Anyways, since I don't see macros in the camel book, I figure they're not going to be explicitly covered in any of the apocalypses, so I was hoping to inspire a little discussion here. This email is more an unorganized but related group of thoughts, which I'm hoping to use to start a useful discussion on how to Perl-ify Lisp's powerful macros to make them easier to work with. I can organize it into an formal proposal or RFC if that would help. But reading the above book, or at least understanding the concepts behind them, would be helpful in any communication over this matter. Thanks, Mike Lambert
