Re: parser generator terminology

Chris F Clark <cfc@shell01.TheWorld.com>
Mon, 07 Sep 2009 14:27:44 -0400

          From comp.compilers

Related articles
parser generator terminology rpboland@gmail.com (Ralph Boland) (2009-09-06)
Re: parser generator terminology mhelvens@gmail.com (Michiel) (2009-09-06)
Re: parser generator terminology DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-09-06)
Re: parser generator terminology cfc@shell01.TheWorld.com (Chris F Clark) (2009-09-06)
Re: parser generator terminology cfc@shell01.TheWorld.com (Chris F Clark) (2009-09-07)
Re: parser generator terminology haberg_20080406@math.su.se (Hans Aberg) (2009-09-07)
Re: parser generator terminology mhelvens@gmail.com (Michiel) (2009-09-07)
Re: parser generator terminology cfc@shell01.TheWorld.com (Chris F Clark) (2009-09-07)
Re: parser generator terminology haberg_20080406@math.su.se (Hans Aberg) (2009-09-09)
Re: parser generator terminology cfc@shell01.TheWorld.com (Chris F Clark) (2009-09-13)
Re: parser generator terminology haberg_20080406@math.su.se (Hans Aberg) (2009-09-14)
Re: parser generator terminology gneuner2@comcast.net (George Neuner) (2009-09-14)
| List of all articles for this month |
From: Chris F Clark <cfc@shell01.TheWorld.com>
Newsgroups: comp.compilers
Date: Mon, 07 Sep 2009 14:27:44 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 09-09-038 09-09-039 09-09-045
Keywords: parse
Posted-Date: 09 Sep 2009 11:15:45 EDT

Hans Aberg <haberg_20080406@math.su.se> writes:


> Michiel wrote:
>>> 1) Is there a name for the definition of the set of tokens; preferably
>>> a short name useful for naming identifiers? (I do not like regular
>>> definition since it implies a set of rules I do not follow.)
>>
>> Not that I know of. What about 'vocabulary'?
>
> In Waite & Goos, the vocabulary V is the (disjoint) union of the sets of
> non-terminals and terminals. They first defines ageneral rewriting
> system, with sentences members of V*, the set of finite strings (the
> free monoid) of V.
>
> One might call non-terminals "(grammar or syntactic) variables", and
> terminals "(grammar or syntactic) constants"; a joint name for both
> might be "symbols" (or we decided in Bison I think).


While I'm not so foolish as to argue with Waite, Goos, or the Bison
maintainers, epseically when I've Seen V, VT, and VN used rather
universally as the 3 sets of all symbols, terminals, and
non-terminals, there is precedence for vocbulary as VT, given that
Terence Parr uses it in ANTLR if I recall correctly.


However, clearly naming is a hard thing, and most good short words
will already carry some previous usage that will be confusing or
contradictory with whatever convention one uses. And, while I find
single letter names too short (sorry mathematicians, but it seems to
obscure your work not clarify it), the convention of V, VN, VT,
\Sigma, are pretty well established. I'd have to go find a paper to
recall the rest of the 1 letter names that are commonly
used--e.g. IIRC P is the set of productions, G is the goal symbol.


Now, I would think one could expand the 1 letter names into longer
strings, V=vocab, VT = vocab_term, VN = vocab_nterm, sigma and still
be clear of how one is leveraging the theory. However, my expereince
is that if you have a term that one uses enough, one can get a way
with quite a short name, e.g. VT might be clear enough in context that
you don't need a longer form. If I talk about a SR-conflict, I can
assume most of my readers will know what that means without calling is
a shf_rdc_cfl which would be the standard abbreviation in Yacc++,
since in most places I can't use S for shift as it wouldn't be clear
if I meant state.


Hope this helps,
-Chris


******************************************************************************
Chris Clark email: christopher.f.clark@compiler-resources.com
Compiler Resources, Inc. Web Site: http://world.std.com/~compres
23 Bailey Rd voice: (508) 435-5016
Berlin, MA 01503 USA twitter: @intel_chris
------------------------------------------------------------------------------



Post a followup to this message

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