Re: no reserved words

Chris F Clark <>
12 Mar 1998 23:16:17 -0500

          From comp.compilers

Related articles
no reserved words (1998-03-08)
Re: no reserved words (Chris F Clark) (1998-03-12)
Re: no reserved words (Jerry Leichter) (1998-03-13)
Re: no reserved words (William D Clinger) (1998-03-15)
Re: no reserved words (Stephen P Spackman) (1998-03-18)
Re: no reserved words (Sandeep Dutta) (1998-03-18)
| List of all articles for this month |

From: Chris F Clark <>
Newsgroups: comp.compilers
Date: 12 Mar 1998 23:16:17 -0500
Organization: The World Public Access UNIX, Brookline, MA
References: 98-03-091
Keywords: parse

Hugh Gleaves asked:
> I Would Like To Know If Common Tools Like Lex And Yacc, Are Capable Of
> Handling Languages That Have No Reserved Words.

Contrary to other informed opinions, it is possible and not
specifically difficult to do so in yacc like tools, once you know how.
Numeroues customers of Yacc++ have languages which have the no
reserved word rule (and Yacc++ has certain keywords which are not
reserved words and certain keywords which are). By the way, by using
a tool to do this, you will have a more sound compiler, in that you
will know exactly which places the keyword takes its reserved meaning
and where it is just an identifier. That information is often
difficult to obtain in a hand-written recursive descent compiler (and
more importantly harder to keep from accidentally changing as the
parser is maintained).

The basic technique is to define an identifier non-terminal in your
parser grammar, which accepts not only identifiers but also each of
the keywords which are not reserved.

identitifer: ID | keyword1 | keyword2 ... ;

Next, you use the non-terminal everywhere your grammar expects and
identifier (rather than the token ID).

expression : expression '+' expression
                      | identifier ; // keywords allowed as variable names

Next, you run the tool and determine what conflicts it detects. These
will be conflicts which one of the choices is to reduce your
"identifier" non-terminal. Generally the other alternative will be to
shift one of the keywords, and that indicates a spot where the keyword
potentially should take on its reserved meaning and not be treated as
an identifier.

You inspect the tables at each of these conflicts and determine what
the appropriate action is. This is the one step that requires
thought, in that you must carefully look at what is being parsed and
decide which interpretation is the correct choice (and then I
recommend rewriting the parts of the grammar which caused the conflict
to eliminate the ambiguity).

Hope this helps,

Chris Clark Internet :
Compiler Resources, Inc. CompuServe : 74252,1375
3 Proctor Street voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)
Web Site in Progress: Web Site :

Post a followup to this message

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