Re: Problems with an LL(1) language. (Chris Hargrove)
18 Sep 1998 23:05:18 -0400

          From comp.compilers

Related articles
Problems with an LL(1) language. (Alan Southall) (1998-09-13)
Re: Problems with an LL(1) language. (1998-09-18)
| List of all articles for this month |

From: (Chris Hargrove)
Newsgroups: comp.compilers
Date: 18 Sep 1998 23:05:18 -0400
Organization: Concentric Internet Services
References: 98-09-040
Keywords: parse, LL(1)

>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 don't know of any simple way to avoid using semantics in some form.
You can modify the grammar to deal with type names differently than
other identifiers, but to do so it's generally convenient once a type
name is registered in the symbol table to have your lexer return a
type name token instead of an identifier token to facilitate that. If
you look at a standard C grammar for example, TYPE_NAME is a distinct
token from IDENTIFIER and all the type-based rules (type_specifier
etc.) depend on that distinction. So you can keep your grammar clean
if you're willing to sacrifice that bit. It may be semantics, but at
least it's semantics that the lexer can hide for you.
Chris Hargrove
Programmer, 3DRealms Entertainment

Post a followup to this message

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