At 16:06 + 2005/03/07, Derek M Jones wrote:
>Frank,
...
>Your grammar contained a single %merge. I thought at
>least two are required?
I think that you should just merge together the tokens becoming
indistinguishable by your exclusion of context-information. You then get
certain reduce/reduce
At 02:14 + 2005/03/07, Derek M Jones wrote:
>>Paul Hilfinger is thinking about actions that during a split are executed
>>immediately, in addition to those delayed until the merge. This will enable
>>the kinds of things that you are asking for, I think, as one then can build
>>the parse trees,
At 18:12 + 2005/03/06, Derek M Jones wrote:
>Unfortunately glr parsing is not a universal solution. It requires that
>at the end of processing there be a unique parse tree (the multiple
>parse trees that may exist while processing the input tokens are required
>to eventually resolve to a singl
Derek M Jones wrote:
> The problem comes with '(x) + (y) + z' (which I gave as
> a example on comment in this thread, rather than starting a
> new thread; as if people were not confused enough).
> There are four possible parses of this expression: two
> of which are causing my current problem. Th
Frank,
>> >Have you looked at `%merge'?
>>
>> That option has the limits on its use as %dprec.
>
>Which limits exactly? I tried it with your original example
>`x + (y) + z' and it seems to work well (see attachment).
%dprec also works fine with the this, original, example.
The problem comes wit
$B$O$8$a$^$7$F!#$f$+$j$C$F$^$9!#(B
$B%;%C%/%9%U%l%s%I$rJg=8$7$F$^$7$?$h$M!)(B
$B$o$?$7!"1~Jg$7$F$b$G$7$g$&$+!)(B
$B$(!<$H!"H`;a$O$$$k$s$G$9$,!"K~B-$7$F$J$/$F!"(B
$B$<$R!"%(%C%AM'C#$K$J$C$F$[$7$$$G$9!#(B
$B=;$s$G$k=j!"6a$$$_$?$$$J$N$G!"(B
$B$^$:$O%([EMAIL PROTECTED](B
$B%+%s%?%
Derek M Jones wrote:
> Frank,
>
> >> Unfortunately glr parsing is not a universal solution. It requires that
> >> at the end of processing there be a unique parse tree (the multiple
> >> parse trees that may exist while processing the input tokens are required
> >> to eventually resolve to a sin
Frank,
>> Unfortunately glr parsing is not a universal solution. It requires that
>> at the end of processing there be a unique parse tree (the multiple
>> parse trees that may exist while processing the input tokens are required
>> to eventually resolve to a single parse).
>
>Have you looked at
Derek M Jones wrote:
> Unfortunately glr parsing is not a universal solution. It requires that
> at the end of processing there be a unique parse tree (the multiple
> parse trees that may exist while processing the input tokens are required
> to eventually resolve to a single parse).
Have you lo
