[Newcompiler] Re: About error handling in Smacc

[stéphane ducasse]

tx john
On 22 août 06, at 19:27, John Brant wrote:

> stéphane ducasse wrote:
>
>> mathieu is working on improving the Smacc based parser-compiler of
>> Squeak and right now
>> what is missing is a better way to handle error. Is there a way to
>> improve the user feedback?
>>
>> I do not know how we can do that in Smacc. Do you have some pointers?
>> I thought about the RBHightlighting as an example but I'm not sure if
>> this is correct.
>
> I have a couple of ideas that I've never tried, but you could try. The
> first is to use the special "error" token. For example, if you are
> parsing an parenthesized expression, you can make other versions that
> use the "error" token:
>
> Expression
> 	: "(" Expression ")"
> 	| "(" Expression error {self signalError: 'Missing ")"'  
> beforeToken: '2'}
> 	| "(" error {self signalError: 'Missing expression' beforeToken: '2'
> "-- for an expression like ()"}
> 	| ...other rules...
> 	;
>
> (assuming that you've defined a #signalError:beforeToken: method)
>
> The RBHighlighter uses the error token extensively. However, it just
> underlines the problem, and doesn't give the user any idea of what the
> error really is.
>
> Another approach would be to create the id methods for each of the
> tokens, and use the #actionFor: method to test what state you are in.
> For example, you could create a token id method for ")", and then when
> you get an error (#handleError:) you could test whether the current
> state accepts an ")" token -- "(self actionFor: self  
> rightParenthesisId)
> ~= self errorAction ifTrue: [self signalError: 'Missing ")"  
> beforeToken:
> currentToken]".
>
> Smalltalk has an easy enough grammar that either of these should work.
> I'm guessing that the error token approach might be simpler though. A
> combination of both might work best -- for example, use the error  
> token
> in some well defined places, but use the #handleError: with the token
> ids in the other places.
>
>
> John Brant