By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,312 Members | 1,877 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,312 IT Pros & Developers. It's quick & easy.

recursion in grammar?

P: n/a
I'm trying to create Python parser/interpreter using ANTLR.
Reading grammar from language refference I found:
or_expr::= xor_expr | or_expr "|" xor_expr

For me it looks like infinite recursion. And so it says ANTLR. Maybe I
don't understand EBNF notation. For me it should look like this.
or_expr::= xor_expr | xor_expr "|" xor_expr

and in ANTLR grammar file like this:

or_expr: xor_expr { "\|" xor_expr }, or rather
or_expr: xor_expr ( "\|" xor_expr )*

Do I think good?
ANyone heard of Python grammar for ANTLR?
Jul 18 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
pe*******@poczta.onet.pl (Peri) writes:
I'm trying to create Python parser/interpreter using ANTLR.
Reading grammar from language refference I found:
or_expr::= xor_expr | or_expr "|" xor_expr

For me it looks like infinite recursion.
Isn't this just left recursion (a standard LL(1) trick)?
And so it says ANTLR. Maybe I don't understand EBNF notation. For
me it should look like this. or_expr::= xor_expr | xor_expr "|"
xor_expr


That wouldn't let you write "1 | 2 | 4", would it?

It's not really different from recursion in programming languages (or
mathematical induction) -- the Python grammar is a finite way of
describing sequences of tokens of arbitrary length. You have to have
*some* trick like recursion in there for this to work.

I can't help you with ANTLR.

Cheers,
mwh
--
I would hereby duly point you at the website for the current pedal
powered submarine world underwater speed record, except I've lost
the URL. -- Callas, cam.misc
Jul 18 '05 #2

P: n/a

"Peri" <pe*******@poczta.onet.pl> wrote in message
news:34**************************@posting.google.c om...
I'm trying to create Python parser/interpreter using ANTLR.
Reading grammar from language refference I found:
or_expr::= xor_expr | or_expr "|" xor_expr

For me it looks like infinite recursion.


Better to call it unbounded recursion. This is what makes general CF
languages/grammars more extensive/powerful that regular languages.

In particular, the recursion is written as left recursion.
The equivalent right recursion would be
or_expr::= xor_expr | xor_expr "|" or_expr
The recursive 'call' is to the right of the connector literal instead of
the left.

There are two types of linear CF parsers: bottom-up LR and top-down LL.
Each handles recursion written one way and chokes on recursion written the
other way. The two types have opposite requirements. (I forget which is
which.) Since Antler choked on left recursion, I presume that it is the
'other' type than Python's and that it requires right rather than left
recursion. So try reversing all the recursive definitions. (Or try first
the one that gives first error message and see if you get farther.)

Terry J. Reedy
Jul 18 '05 #3

P: n/a
On Sat, 27 Dec 2003 13:04:15 -0500, "Terry Reedy" <tj*****@udel.edu>
wrote:

"Peri" <pe*******@poczta.onet.pl> wrote in message
news:34**************************@posting.google. com...
I'm trying to create Python parser/interpreter using ANTLR.
Reading grammar from language refference I found:
or_expr::= xor_expr | or_expr "|" xor_expr

For me it looks like infinite recursion.


Better to call it unbounded recursion. This is what makes general CF
languages/grammars more extensive/powerful that regular languages.

In particular, the recursion is written as left recursion.
The equivalent right recursion would be
or_expr::= xor_expr | xor_expr "|" or_expr
The recursive 'call' is to the right of the connector literal instead of
the left.

There are two types of linear CF parsers: bottom-up LR and top-down LL.
Each handles recursion written one way and chokes on recursion written the
other way. The two types have opposite requirements. (I forget which is
which.) Since Antler choked on left recursion, I presume that it is the
'other' type than Python's and that it requires right rather than left
recursion. So try reversing all the recursive definitions. (Or try first
the one that gives first error message and see if you get farther.)


Unless I am seriously mistaken, bottom-up LR parsers do not choke on
either left or right recursion. Right recursion, IIRC, requires
unbounded stack space in principle, but works OK in practice for the
simple reason that the input always defines a finite bound. It is
certainly less efficient, and carrys the risk that a complex input
might overflow the available stack space, but those are rarely serious
issues these days.

If LR parsing could not handle both left and right recursion, it
equally could not handle both left-associative and right-associative
operators. Of course most real parsers have specialised support to
optimise these common cases, but pure-form bottom-up LR parsing
algorithms such as LR(1) and LALR(1) are perfectly capable of handling
both left and right associative operators, and they do so using left
and right recursion as appropriate.

Which raises an important point - if you change the grammar to swap
the recursions from left to right or whatever, that results in a major
code-breaking change in how the parser interprets the language.
Left-associative expressions will be parsed as right-associative and
visa versa. Maybe worthwhile as a test to see what happens, but no
good for a final parser that is intended to work on real Python code.
Well, not without some post-processing of the resulting AST anyway.

ANTLR definitely uses LL parsing. I don't know about Pythons parsing
engine, though I suspect it uses LR-style parsing. It is a basic fact
of life that LL parsers and LR parsers do have quite different
limitations, and if Python uses LR parsing it will probably be
impossible to build a parser for the (unmodified) Python grammar using
an LL tool such as ANTLR. However, I find it hard to believe that
ANTLR has no means of working around these issues with some relatively
simple tweaks to the grammar specification.

I would raise the question in comp.compilers, or check if ANTLR has a
mailing list.
--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk
Jul 18 '05 #4

P: n/a
Stephen Horne <st***@ninereeds.fsnet.co.uk> writes:
ANTLR definitely uses LL parsing. I don't know about Pythons parsing
engine, though I suspect it uses LR-style parsing.


Nope, LL(1). One thing you should note is that the grammar in the
docs is *not* the grammar used by Python's parser generator -- that's
Grammar/Grammar in the source distribution. I'm not sure, but I
suspect that the grammar in the docs is nastily ambiguous. Certainly
the actual Python parser lets through some stuff that get's thrown out
in the compiler with SyntaxErrors.

Cheers,
mwh

--
Good? Bad? Strap him into the IETF-approved witch-dunking
apparatus immediately! -- NTK now, 21/07/2000
Jul 18 '05 #5

P: n/a
Michael Hudson <mw*@python.net> wrote in message news:<m3************@pc150.maths.bris.ac.uk>...
Stephen Horne <st***@ninereeds.fsnet.co.uk> writes:
ANTLR definitely uses LL parsing. I don't know about Pythons parsing
engine, though I suspect it uses LR-style parsing.


Nope, LL(1). One thing you should note is that the grammar in the
docs is *not* the grammar used by Python's parser generator -- that's
Grammar/Grammar in the source distribution. I'm not sure, but I
suspect that the grammar in the docs is nastily ambiguous. Certainly
the actual Python parser lets through some stuff that get's thrown out
in the compiler with SyntaxErrors.

Cheers,
mwh


Even the file Grammar/Grammar isn't quite LL(1). It's close, but not
quite. For example:

comp_op: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'|'is'|'is'
'not'

Would never be able to get to the 'is' 'not' section with LL. I
believe the parser generator straightens this out when it builds the
DFA's.
Jul 18 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.