Problems with an LL(1) language.

Alan Southall <alan.southall@bk.bosch.de>
13 Sep 1998 22:43:59 -0400

          From comp.compilers

Related articles
Problems with an LL(1) language. alan.southall@bk.bosch.de (Alan Southall) (1998-09-13)
Re: Problems with an LL(1) language. chrish@3drealms.com (1998-09-18)
| List of all articles for this month |

From: Alan Southall <alan.southall@bk.bosch.de>
Newsgroups: comp.compilers
Date: 13 Sep 1998 22:43:59 -0400
Organization: Bosch Telecom
Keywords: parse, LL(1), question

Hello,


I've been designing a new language using JavaCC (about 250 prod.
rules) and have tried (successfully) up until last week to describe
the whole thing as LL(1). The problem I have now is with expression
and casting. I have defined one production rule which can take an
expression in brackets or a cast followed by a primary expression. The
problem comes with references to identifiers, i.e. it is ambiguous as
the parser cannot tell whether or not an identifier is a reference to
a variable/constant/whatever or a type. The obvious thing to do would
be to apply some kind of semantics and look in the symbol table to
make a decision - but I don't like this solution (I personally think
its messy). I basically want to maintain my LL(1) property and still
allow casting and expressions in brackets.


I thought about adding a keyword cast which is related to semantic
rules, e.g.


x BYTE;
y WORD = 10;
z WORD = 5;


x = CAST (y + z);


As the compiler knows that the LHS is a BYTE, it can automatically
cast to the desired type (BYTE) (possibly with the loss of data).
I then thought about adding to this as follows:


x = CAST (y + z) ELSE { x = 0; }


or


x = CAST (y + z) ELSE { THROW exception1; }


Which would selectively enable run-time boundary checking so that the
user can catch errors in cast statements. The language is meant for
systems which require high levels of safety so this would fit in, but
I'm not convinced + I don't want to keep adding keywords + I suspect
that with more complex expressions, the grammar rules and casting may
become confusing.


If anyone got any opionions/suggestions/references to papers, etc.
for the above I would be very grateful.


Thanks in advance,
Alan.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.