Derek M Jones wrote:
> >> Your grammar contained a single %merge. I thought at
> >> least two are required?
> >
> >All the involved (top-level) rules must have a `%merge'. In the
> >original example, both happened to be the same rule.
>
> Thanks for a great example. It looks like the implementa
f %dprec.
Or perhaps %dprec should be made as general as %merge.
%glr-parser
%token ID
%{
#include
#include
static const char *input = "(x)+(y)+z";
#define YYSTYPE char *
static void yyerror (const char *s)
{
printf ("%s\n", s);
}
static YYSTYPE stmtMerge (YYSTYPE
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 c
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 thi
d
> >> to eventually resolve to a single parse).
> >
> >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).
If y
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
Hans,
>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, and make a selection based on that.
I think
At 18:12 + 2005/03/06, Derek M Jones wrote:
>> You then get the correct parse
>>trees, and need only decide how to select one over the other. Clearly, this
>>choice cannot be done, in general, unless you somehow supply the context
>>information missing.
>
>Unfortunately glr parsing is not a uni
ich parse to use
in some circumstances (i.e., both parses must involve the same sequence
of tokens), but not all.
I am current trying to figure out why
(x) + (y) + z;
(which can be parsed in four different ways) is generating an ambiguity
(it should be handled by my existing uses of %dprec and
At 17:03 + 2005/03/06, Derek M Jones wrote:
>>You are not processing the C language, but some other language, with the
>>context dependencies of the C language removed.
>
>Correct. I only claim to be processing C syntax on a
>single statement/declaration basis (and then only at the visible
>so
Frank,
>(Please reply in the list.)
Ok (your last reply did not look at if it came via
the list, so I responded to you only).
>> For this grammar I don't build a symbol table.
>
>Then how do you distinguish between cast and other parentheses in
>the semantics phase as you say? Or evaluate semant
Hans,
>You are not processing the C language, but some other language, with the
>context dependencies of the C language removed.
Correct. I only claim to be processing C syntax on a
single statement/declaration basis (and then only at the visible
source level)..
> Perhaps check the newsgroup
>c
At 14:43 + 2005/03/05, Derek M Jones wrote:
>>The normal way to resolve this would be to let the lexer check the lookup
>>table to see what y is: a type or a number identifier, and then return that
>>type. WHy does this not work for you.
>
>Because I don't have a symbol table to look things up
(Please reply in the list.)
Derek M Jones wrote:
> Frank,
>
> >> Since both parses will recognise the input one has to be
> >> selected. Picking the common case means that there is
> >> less work which has to be undone later in the semantics phase.
> >
> >Undoing and reversing parsing (as you a
Hans,
>At 20:41 + 2005/03/03, Derek M Jones wrote:
>>The statement (y)+z can be parsed as casting
>>+z to the type y, or as adding y to z. A couple of
>>%dprecs solve this problem (I think the cast is the
>>common case for - and a binary expression for +).
>
>The normal way to resolve this wo
Derek M Jones wrote:
> >> The statement (y)+z can be parsed as casting
> >> +z to the type y, or as adding y to z. A couple of
> >> %dprecs solve this problem (I think the cast is the
> >> common case for - and a binary expression for +).
> >
> >What the "common case" is doesn't really matter sin
ld be to let the lexer check the lookup
table to see what y is: a type or a number identifier, and then return that
type. WHy does this not work for you.
>However, things are more complicated for x + (y) + z,
>whose parse tree can be either
>
>+
>
Frank,
>> The statement (y)+z can be parsed as casting
>> +z to the type y, or as adding y to z. A couple of
>> %dprecs solve this problem (I think the cast is the
>> common case for - and a binary expression for +).
>
>What the "common case" is doesn't really matter since a correct
>parser shoul
Kelly,
>> to
>>
>> add-expr:
>> mul-expr|
>> mult-expr '+' add-expr |
>> mult-expr '-' add-expr ;
>>
>
>I don't think that's what you want if you're planning
>on executing the code you generate from this...
A subsequent phase
ote:
> All,
>
> The statement (y)+z can be parsed as casting
> +z to the type y, or as adding y to z. A couple of
> %dprecs solve this problem (I think the cast is the
> common case for - and a binary expression for +).
> However, things are more complicated for x + (
Derek M Jones wrote:
> The statement (y)+z can be parsed as casting
> +z to the type y, or as adding y to z. A couple of
> %dprecs solve this problem (I think the cast is the
> common case for - and a binary expression for +).
What the "common case" is doesn't really matter since a correct
parse
> to
>
> add-expr:
> mul-expr|
> mult-expr '+' add-expr |
> mult-expr '-' add-expr ;
>
I don't think that's what you want if you're planning
on executing the code you generate from this...
This means that 3 - 4 + 4 = -5, rather
All,
The statement (y)+z can be parsed as casting
+z to the type y, or as adding y to z. A couple of
%dprecs solve this problem (I think the cast is the
common case for - and a binary expression for +).
However, things are more complicated for x + (y) + z,
whose parse tree can be either
27 matches
Mail list logo
