You really need to answer the question "What will I do with the macro system" before you have any hope of a design.

Some things, like the compile-time text transformation that C's preprocessor does, is best done with source filters, and at this point is both doable and pretty simple.

Fancier things, like adding new syntax (such as the switch statement or whatever) are best done by actually adding new syntax to the parser and compiler, putting it outside the realm of macros.

You might want to go ahead and mess with tokens--for example changing the definition of + for a lexical scope, but that's best done either by a change to the parser (and thus a change to the underlying language) or a change to the compiler's rules for tokens, both of which are best done in either the parser grammar language or by adding a few regexes and rules to the compiler. (Which, I suppose, could be considered macros of a sort, though I wouldn't)

So what do you want to do with the macros? Until you answer that, there's not much to be done to design the things.

You really need to answer the question "What will I do with the macro system" before you have any hope of a design.

I was rather hoping we could do it togther. My thoughts on the subject are rather scattered, actually. Perhaps I'm not much of a language designer?

That said, I think you are essentially correct. It's difficult to motivate a discussion of a feature if you can't even propose some example uses. Perhaps I'll take another pass if I can come up with some.

It's difficult to motivate a discussion of a feature if you can't even propose some example uses.

I thought "switch" was a good example, even though the syntax was less-than-pleasant. What I'd like to see is something to add rules to the running parser (a la Parse::RecDescent), using the same language as Perl to define the new rules (including Perl itself to express actions). In other words, I could do something like this:

This would extend the existing grammar by adding to the 'expr' rule and creating new rules 'slice' and 'stride'. It would also define the new semantics, probably returning an AST representing the appropriate Perl code.

Lisp gets away with this because the syntax is so... simple. In Perl there would probably be an infinity of ways to hurt yourself trying to do this, and lots of people would, so the diagnostics would have to be very good. This might always end up as a "you have to be THIS tall" feature...

So at least three hard things stand in the way of this: making a stable and extensible API for construct op-trees, writing a comprehensible Perl grammar in top-down format, and creating a good grammar checker. But wouldn't it be loveley