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

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]

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.

For the first part, I'd be inclined to say "it's just syntax." Granted, it's _important_ syntax -- we shouldn't force new syntax on programmers unless absolutely necessary -- but _if_ this is actually something a lot of people want to use, would it be hard to make the syntax perlier? Perl5 may not be the best language to express rules, but I get the feeling that Larry's eminent integration of regex backtracking with the rest of the language may change that somewhat.

For the second -- I personally think top-down is more intuitive, but I don't think the "reconfigure the parser" idea is necessarily tied to "the parser" being top-down. Also, the possibility of doing something like this could factor into your definition of "best".

/s