[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SableCC Thoughts Part II
Dan Sandberg wrote:
> Anyone interesting in writing a DepthFirstObjectVisitor like JTB has?
> It returns an object at every production, thus allowing values to
> 'trickle up' through the parse hierarchy. This seems more convenient
> (though less powerful) than the Hashtable method. It also lets you not
> have to worry about cleaning up the hash table.
I was planning, in SableCC 3.x, to have some kind of scripting language
that would allow SableCC to generate "custom" tree walkers. I know
SableCC 3.x is still far away, but maybe this can just wait, for a
while? One difficulty of your approach is how to handle linked lists
(resulting from using "*").
> For this grammar:
> A = B*
> B = 'x' | D
> D = 'z' 'x'*
> This grammar has a shift-reduce conflict. The String "zx" can be parsed
> as D or DB. My grammar is like this. I would like it to shift, not
> reduce, unless shifting is not possible. I am parsing an existing
> language so changing the language is not an option. How can this be
Byt rewriting an equivalent non-ambiguous grammar, like:
A = B* D*
B = 'x'
D = 'z' 'x'*
Yes it requires some mental gimnastics from the grammar designer, but
the end-users gets an unambiguous description of the parsed language.
How do you expect a user to understand how a program is parsed under
your version of the grammar? Do you expect them to understand what
"shifting" means? Are you sure you really understand yourself?
By looking at my grammar, don't you get a new understanding of your
grammar? For example, now it is clear that once you have read an 'z',
it becomes impossible to get a "B" (in the context of your grammar,
shifting means you won't get the first alternative of B once you have
parsed a D). I doubt you could see this clearly in your grammar.
I am not willing to add into SableCC the wekk know bug prone features of
YACC/Bison and company. It's OK to intruduce clean, well defined
subsets of those features, when it is clear that they won't lead the
average compiler programmer to specify grammars that parse a different
language than they expect.
Etienne M. Gagnon, M.Sc. e-mail: email@example.com
Author of SableCC: http://www.sablecc.org/
and SableVM: http://www.sablevm.org/