Re: SableCC Thoughts Part II

[Dan Sandberg <dan@siliconpoetry.com>]

> That's OK.  I didn't realize your rush.  I think that your code would be
> a nice addition to SableCC.  How familiar are you with SourceForge
> (SF)?  If you want, I can add you as a developer of the project, and
> grant you CVS write access.  I think Mariusz offered to help you.  He
> could possibly take care adding your code in the CVS repository, if it
> is difficult for you to get a functional SF setup. (Thanks, Mariusz!).

I have not used Source Forge before, though I have used CVS.  I would
prefer not to deal with integration and just e-mail the changes to
someone, but I will do it if necessary.

> What I I was suggesting was to separate error recovery in two parts:
> 1- Syntax error recovery: automatic, based on the grammar structure.
> Yields an AST with [error] nodes.  Requires special visitor support.
> 2- Sematic error recovery: handled by the compiler programmer, mostly
> after parsing, while visiting the AST.  Possibility of doing part of it
> at parse time, within semantic predicates.

Yes, I agree this is the right way to do it, I just find it unlikely
that the parser would be able to recover in the optimum way in all
situations.  Since I know the semantics of the grammar I am parsing, I
would like to tell the parser how to recover.
 
> 
> I think that anything beyond error recovery (e.g. "fixing") should only
> be done with "end user" explicit consent.
> 

Sorry, I misspoke.  Yes, I mean error-recovery, not fixing.  I think you
are right that error-recovery could be made largely automatic.  I think
that there are some grammars, however, where because of the semantics of
the language the automatic recovery would lead to suboptimal results. 
In this case, being able to tell the parser how to do the recovery would
be nice.  I think a mechanism as simple as processToken( token ) and
unprocessLastToken() ( to undo previous parse steps ) would be
sufficient.  This would give the programmer a lot of power in handling
error-recovery without exposing the internals of the parsing process. 
If a programmer chooses to use a callback rather than the automatic
recovery, than they are choosing to go outside the safety of the SableCC
environment and need to know what they are doing so as not to cause
infinite loops.  This seems like a fair bargain.

It seems like we agree.  The only question is whether you object to
having the callback mechanism available as well as the grammar-specified
error-recovery.

Also, I was looking at CUPS and I noticed it had a way of specifying
precedence to solve shift / reduce conflicts.  This seems like a very
easy way to solve the program with the ambiguous grammar I have that I
mentioned in a previous message.  Any plans to add this to SableCC? 
This is far outside my area of competence ( I really hated Compilers
class :) ).  If Etienne wants this feature, I'd be willing to pay
someone a bit ($500 US) to get it done quickly.

-Dan