Related articles |
---|
no reserved words hugo@morantek.demon.co.uk (1998-03-08) |
Re: no reserved words cfc@world.std.com (Chris F Clark) (1998-03-12) |
Re: no reserved words leichter@smarts.com (Jerry Leichter) (1998-03-13) |
Re: no reserved words will@ccs.neu.edu (William D Clinger) (1998-03-15) |
Re: no reserved words stephen@acm.org (Stephen P Spackman) (1998-03-18) |
Re: no reserved words sandeep.dutta@usa.net (Sandeep Dutta) (1998-03-18) |
From: | Stephen P Spackman <stephen@acm.org> |
Newsgroups: | comp.compilers |
Date: | 18 Mar 1998 22:45:07 -0500 |
Organization: | Compilers Central |
References: | 98-03-091 |
Keywords: | yacc, parse |
Another technnique to construct parsers for reserved-word-less
languages _of your own design_ is to adopt the view that if there are
no reserved words then "keywordness" is a *semantic* issue. *Don't*
waste space and time in your lexer recognising them. Just store the
'keyword' interpretations of words in the symbol table as another
contextual overload of the name (as you would with a structure field
name, e.g.).
Make it really extensible by putting a pointer to the relevant
processing routine right in there. Now you needn't even recompile the
parser for most language extensions.
Of course, that's going to mean that you will need a syntax for your
language which allows keyword constructs to be parsed without regard
for _which_ keywords appeared. (Well, unless you can feed the symbol
table info forward into the parser, but we were talking about standard
yacc techniques).
This is a limitation.
*But* the stated objective of the keywordlessness was to construct a
language which could be used *without* knowing the full set of all
keywords. If that includes being able to _read_ code that contains
unfamiliar keywords, then the _programmer_ will need to be able to
perform this very task, of recognising structure without knowing the
detailed semantics. In which case, imposing that same stricture on the
language (through the parser) may not be a bad idea at all.
Just a case of "structured language design". (All my keyword-oriented
languages have worked his way.)
- stephen p spackman - |
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.