Re: Re: Re: Re: Re: Re: Re: A Macro System for Perl?

[educated_foo]

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];

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

[Elian]

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>
                     ),

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.

[educated_foo]

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

[Elian]

It's not quite just syntax, though--it's severely restricted syntax. If you want a fast parser, the rules need to be stated in a way that allows the parser rule processor to transform them into a single big glob 'o program. (Generally a state machine, but that's not strictly necessary) The more degrees of freedom you allow in rule specification, the slower and more difficult the parser is to write.

The problem with top-down parsing is that it's slow. The more states and rules, the slower it is. Perl's grammar would take ages to process by a top-down parser.