Re: compiler books, was Looking for Compiler Design in C, by Holub

rkrayhawk@aol.com (RKRayhawk)
15 Dec 1999 01:14:41 -0500

          From comp.compilers

Related articles
Re: compiler books, was Looking for Compiler Design in C, by Holub compres@world.stc.com (Chris F Clark) (1999-11-29)
Re: compiler books, was Looking for Compiler Design in C, by Holub rkrayhawk@aol.com (1999-12-15)
| List of all articles for this month |

From: rkrayhawk@aol.com (RKRayhawk)
Newsgroups: comp.compilers
Date: 15 Dec 1999 01:14:41 -0500
Organization: AOL http://www.aol.com
References: 99-11-178
Keywords: books, comment

Chris F Clark, compres@world.stc.com
Date: 29 Nov 1999 00:19:41 -0500
writes;


<<
Unfortunately, I have yet to find a book that
does a good job of teaching one how to write a grammar.
>>


Now there is a million dollar idea! The most difficult thing to
understand about the grammar tools, for the novice, is that rules can
be concurrently scoped.


In effect the use of the context free tools leads a coder (a coder of
the grammar) into writing a parallel code algorithm, but they ususally
do no know that. Its all so simple they are told.


Shift/reduce and reduce/reduce problems are just parallel coding
errors. For these the novice can be given crutches. Don't worry about
the science, just use these pathways out (like precedence, or
flattening).


In this situation we have one serious problem in the tutorials, books
and examples. We call recursion 'recursion', and it is not recursion.


In parallel code you do not recurse! Instead at a high level you are
simply competing with the concurrently scoped rules. What we call
recursion in grammar tools is really self-competition, where a rule
begins to compete with itself. Approximately! :-)


My point is that we do not teach that grammars are specifications of
competing, parallel, encodings. Which is a problem. And so when we use
the word recurse, which is a sequential code concept, we damage the
chance a student can understand what is happening.


We do not have as yet a vocabulary that is understandable to the
novice to depict the basic program concepts of parallel
programming. We only need a subset of that to describe parser grammar
code work.


If the vocabulary were different it would probably not be hard to
teach self-competition in rules, nor the need for exit from a
self-competitive nesting (the need for a unique exit from a
self-competing rule, is really a need to stop self-competing!).


If we had a vocabulary, we could probably make it obvious that
competing rules that all start with epsilon, naturally are ambiguous.


If recurse, epsilon, and 'error' are conceived of as components in
parallel programming, then it might be easier to explain the tools
that have these building blocks.


Best Wishes
Bob Rayhawk
RKRayhawk@aol.com
[If I ever revise lex&yacc, the two things I'll add are grammar design
and building in-memory ASTs. -John]


Post a followup to this message

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