[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SableCC Thoughts Part II
I will do the error-recovery functionality this weekend, but in a kludgy
way since I'm not sure how to solve the multiple reduction before error
problem I mentioned in the last message. Etienne, please give the
go-ahead (or not) for the other enhancements we've been discussing.
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've noticed that the toString() methods of tokens adds spaces. It
seems to me that it would be better if the productions that used these
tokens added spaces between the tokens. This is because often in a
grammar you have:
animal = dog | cat | mouse;
where dog, cat, and mouse are tokens. In your visitor you would like to
be able to get the value. If spaces were not added (except BETWEEN
tokens) you would be able to do AAnimal.toString() to get either 'dog',
'mouse', or 'cat', instead of 'dog ', 'mouse ', and 'cat '. Obiously
you can always trim the spaces off, but why should that be necessary?
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
handled? Does it require Semantic Look-Ahead? How could that be added
to SableCC? Basically, I want to tell it "If D is at the top of the
stack, solve shift/reduce conflicts by shifting". Any clue? Right now
I'm thinking of handling it by changing the grammar so that D has a
token at the end, which would never really exist. So the error recovery
(that is being added) would be called, and I could solve it by sticking
stuff on the stack or not. This seems terrible though.