I was referring to abuse, not robustness. Like any other form of syntax or semantics alteration (operator overloading comes to mind), there are good reasons to have the opportunity (operator overloading comes to mind), but making use of it just because you can will easily create a maintenance nightmare (operator overloading comes to mind). And operator overloading is a relatively mild form of this. Perl 6 will allow really drastic interventions.

I am excited about the possibilities, but I hope people use the opportunity carefully. It'll most likely turn out to be one of those things you should not do unless you know why you not.

Makeshifts last the longest.

Also, rule based syntax modification is lexically scoped, which is definitely handy...

How exactly is that supposed to work? It seems a bit paradoxical to me. Allowing lexical modification of the parser would have to happen at run-time; the only problem being that run-time is after compile-time :) I was under the impression that the process would be more like:

1. The code must be in a BEGIN block or be use'd (same thing).
2. The BEGIN block is parsed, compiled, and run with the current parser.
3. When it is evident that parser rules are being overwritten, a copy of the parser is made.
4. Modifications to the parser are actually made on the copy.
5. When the BEGIN block exits, the modified parser becomes the real parser.

Don't forget that uses are compile-time things. You throw the parser modification code into a module and use it in the block that you want it in effect for. The module then pushes the changes to the parser module out to the user's scope. Then, when the compiler continues on it uses the new parser code.

Something like the way strict works now, pushing things out to its caller.

So, will this code die 50% of the time?

{
    $type = ('hex','oct')[rand 2];
    eval qq[
        rule Perl::Literals::$type::number {
            {die 'this base no longer exists'}
        }
    ];
    print 0o017;
}
[download]