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) |
From: | chrish@3drealms.com (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
chrish@3drealms.com
http://www.3drealms.com
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.