develooper Front page | perl.bootstrap | Postings from July 2000

Parsing issues (Was: Working Group Proposal)

Moore, Paul
July 25, 2000 01:11
Parsing issues (Was: Working Group Proposal)
Message ID:
From: Nick Ing-Simmons []
> What it means it you can tell what construct means by looking 
> at next 'symbol'. perl5 contorts itself to be able to use byacc
> (which is LALR(1)) by making deciding what the next 'symbol'
> is rather a complex process in toke.c.
> As a result the 'grammar' in perly.y does not really describe 
> perl5 that well.
> So making perl6 LALR(1) "from the outset" would give "_P_erl" 
> a more formal definition.

Alternatively, by abandoning the attempt to use a LALR(1) tool to parse a
grammar which is not LALR(1), we avoid the complexity of toke.c.

The question remains, what is the scope and direction of acceptable language
change? Is the priority on formal specifiabilty and parsability, or on
expressiveness and flexibility. Or can these two be combined in a useful

IMHO, Perl's *syntax* is fine. (Once you accept the punctuation-heavy
approach, which is really a lexical issue...) The *implementation* of that
syntax is an issue, and some of the semantic consequences are nasty, but the
basic syntax is what I *like* about Perl.

Even the indirect-object slot stuff. I know what I mean, just because the
computer can't parse it correctly, that's not my problem... (Seriously,
there are areas where the parsing problem is just too hard, but I still see
DWIM as a valid principle, in the context of Perl syntax).


BTW, if the issue is the availability of non-LALR(1) parser generators, it
may be worth someone who understands these things looking at ANTLR
( It's a parser generator, reputedly stronger than LALR,
written in Java which can spit out Java or C++ parsers. Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About