On Fri, Apr 27, 2012 at 5:03 AM, Zefram <zefram@fysh.org> wrote:
> David Nicol wrote:
>>Adding that declaration, then altering bits of perly.y to allow the
>>proposed syntax, would be a good way to become familiar with perly.y.
>
> It would be frustrating, since you'd eventually realise that the
> procedural code that is used throughout perly.y requires ambiguities
> to be resolved very early, and in particular before you parse the
> parenthesised expression following "if" if "if" can be an expression.
> Practical parsing, particularly of Perl, is often a long way from
> parsing theory.
I believe you; you're credited with checking in a full 34% of that file.
How about the approach of launching a new yyparse instance at
if (
and running it only until it hits an extra r_par? That would provide
the needed surgical extended lookahead, and IF could then fork into
IF_FOLLOWED_PARENS which would appear before plain IF in the rules at
the lexer.
>>various perl-in-perl projects could benefit from building from the
>>same source rather than iteratively adjusting.
>
> In the general case, parsing Perl code requires executing arbitrary Perl
> code (most obviously in BEGIN blocks). The attempts to parse Perl any
> other way are doomed; better to make it easier to call into the real
> Perl parser.
Okay; I guess there's never going to be a way to correctly handle variants on
eval join('', qw/ u s e /,' ',qw/f o o/)
thanks
--
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" are to be interpreted using situational ethics.
Thread Previous
|
Thread Next