[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 "*").

What bubbles up is the return value of the last element in the linked
list.  Not perfect, obviously, but it will make my coding easier.  I
actually want this enough that I will write it in the next few days.  I
looked at the Macro stuff and it doesn't seem too difficult to do this. 
No harm in more visitors, right?

> > 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?
> 
> 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.

You're totally right.  I'm not sure how I missed that.  Thanks, you just
saved me from coding a really aweful hack.

-Dan