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
Frank,
>> 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 implementation of
%merge is different
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
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
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
Hans,
>You ignore the context information distinguishing between type-names and
>number-names. So set these names equal to the same token, and let the GLR
>parser handle it. It then produces all correct parses, including the
>possible type-name/number-name choices.
This is what I am already doing
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
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 would be to let
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
By the way, you might want to have a look at
http://www.lysator.liu.se/c/ANSI-C-grammar-y.html
I don't know if it's different from what you are
working from, and I'm not sure how it does in Bison,
but it might be worth a try.
Kelly
--- Derek M Jones <[EMAIL PROTECTED]> wrote:
> All,
>
> The
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
26 matches
Mail list logo
