[climacs-devel] lisp-syntax and parse tables

[Robert Strandh]

Hello,

Earl J. Wagner writes:
 > 
 > I have a few questions however
 > 1) What's the rationale behind representing parse states as CLOS  
 > objects, as opposed to just numbers?
 > On the one hand this is a little easier to understand when parsing  
 > breaks, but my intuition is that it introduces a lot of overhead.

My thinking was that one might want to put :before and :after methods
on the parser actions.  Also, the traditional table compressions
algorithms seem to boil down to actually defining the equivalent of my
CLOS classes.  Finally, lines in the parse tables are often related by
subset, which suggest that they are related much like a class
hierarchy.  

On the other hand, one can probably define quite a few syntax modules
with only numbers. 

 > 2) Is it necessary to interleave lexing and parsing?
 > It's conventional to have a lexing stage then a parsing stage, but  
 > because of C's macros and other reasons for C++, that doesn't work  
 > for those languages. Correct me if I'm wrong, but Lisp seems uniform  
 > enough that even if you introduce macros or additional syntax, the  
 > lexer should be able to function independently of the parser.

Here, my thinking was to introduce the possibility of nesting
different languages, that might require different lexers.  A simple
example would be to grammar check comments and strings in a language
such as Common Lisp.  A more interesting one would be SQL embedded in
C or PHP in HTML.  

This is another reason I wanted the parser states to be CLOS classes
so that one could use a mixin class to tell the lexer how to behave.  

 > My inclination is to split current-state into a lexer state and parse  
 > state. Lexer state will be identified symbolically as is done now and  
 > the parse state will be represented by state-ids.

I am not sure what the consequences would be.  Perhaps you should test
it on something non-critical such as HTML syntax and see what happens.
If it works out, it could then be introduced in something like Lisp
syntax which is important enough that I would like to avoid breaking
it. 

Take care, 
-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------