(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
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
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
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
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
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 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,
>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
¬¬¬¬¬¬¬¬¬ [EMAIL PROTECTED]@â ¬¬¬¬¬¬¬¬
ªÂ¤¢ ÌqÌã´í說ªªªªªªªªªªªªªªª
[EMAIL PROTECTED]@[EMAIL PROTECTED]@fB[vÅtFeBbV
Èéæ·è¾³ñô
cccccccccccccccccccc
[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTE
