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.

-sam

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:

package Syntax::Stride;



syntax {

slice: array '[' stride ']' {

   # implement this.

}



stride: expr ':' expr ':' expr {

   # and this.

}



expr: slice



} # end of syntax



package main;

use Syntax::Stride;



@a = (1..100);

print @a[1:2:50];
[download]

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

/s

The only problem there is that adding rules to the parser is likely to look more like:

    myour       => qc( my | our | ),

    decl        => qc(
                        package <package_decl>  |
                        module <module_decl>    |
                        class <class_decl>      |
                        sub <sub_decl>          |
                        <@other_declarations>
                     ),
[download]

than perl. Perl's not necessarily the best language to express rules in.

I'm also not sure we're going top-down with the parser. We'll see what works best.