Front page | perl.perl5.porters |
Postings from April 2012
Re: proposal: functional C<if>
Thread Previous
|
Thread Next
From:
David Nicol
Date:
April 26, 2012 19:07
Subject:
Re: proposal: functional C<if>
Message ID:
CAFwScO-nAKeQFWoYRzJQGiNoA3=CZCtMNaxPgZwZ01Z--B=JmA@mail.gmail.com
On Thu, Apr 26, 2012 at 6:49 AM, Abigail <abigail@abigail.be> wrote:
> On Wed, Apr 25, 2012 at 04:27:38PM -0500, David Nicol wrote:
>>
>> Challenge: Can anyone come up with an ambiguous expression where it is
>> not clear if the expression is supposed to be an R-value if-statement
>> (were such things allowed) or a trailing conditional?
>
> Yes and no.
>
> Consider:
>
> push @x => "foo", if (1) {"bar"} else {"baz"};
>
> this isn't ambiguous if you look at it as a whole, but it is ambiguous
> the moment the parser encounters the "if", and it cannot unambiguate it
> by looking one token (or any fixed amount of tokens) ahead -- it actually
> will have to look at the token past the ')' to do so.
>
>
>
> Abigail
So it appears that the answer is, we can't have functional "if"
without either switching from a bison grammar with single-token
lookahead to a more complicated state machine framework with a stack
and arbitrarily long lookahead, to allow looking past the
parenthesized condition, or allowing the construction in only a
limited set of circumstances, which would need to be declared and
maintained as a new parser state, and create yet another pedagogical
nightmare.
http://www.gnu.org/software/bison/manual/bison.html#Generalized-LR-Parsing
hey what do you know, Bison allows arbitrarily long ambiguity if you
want it. The enabling declaration does not currently appear in
perly.y, and there is a linear speed penalty (the reference does not
include benchmark results) when the feature is not needed.
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.
Does a tool exist yet that reads a yacc grammar and outputs a
graph::easy graph or semantic equivalent? With such a thing, the
various perl-in-perl projects could benefit from building from the
same source rather than iteratively adjusting.
--
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