Re: Changing the lookahead token

[Hans Aberg]

On 17 Sep 2012, at 15:41, David Kastrup wrote:

> Hans Aberg <address@hidden> writes:
> 
>> Have you considered the GLR parser? If the correct parse depends on a
>> future lookahead, it will split and join when the correct parse is
>> used.
> 
> But the correct parse does not depend on a future lookahead, but on a
> future _action_, namely actively calling the function and looking at the
> (dynamic) type of its result.  I can't combine this kind of lexical
> tie-in with GLR parsing since GLR parsing will not even _execute_ the
> action _until_ the ambiguity has been resolved.

Let's see if I got this right: You have a function call of the form f x_1 x_2 
...,
and the only way to determine which function argument is valid is by checking 
which f x_1 ... f_k are valid?

>>>> Another might be to use LR(1) which makes sure actions are applied as
>>>> dictated by the tokens.
>>> 
>>> I want to avoid going there.  
>> 
>> One just sets a %define - see the manual.
> 
> Correct me if I am wrong, but LR(1) will do exactly the _opposite_ of
> what I want here by keeping states _separate_ depending on the lookahead
> token.  As far as I can tell it is _exactly_ the state-merging nature of
> LALR(1) that gives me at least a chance to exchange the lookahead token
> without punishment in the first place.

The idea of LALR(1) is merely to make the parser smaller. It compacts the LR(1) 
states in a way that the parse is correct when no error is found, but when an 
error token is found, some additional reductions may be performed before the 
error is issued. Thus, the set of lookahead tokens for each state may not be 
the ones valid at that point in the parse; to see that latter, one may need to 
perform some extra reductions. So it is unsuitable for anything interactive or 
exact error detection.

Hans