[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: x + (y) + z
From: |
Derek M Jones |
Subject: |
Re: x + (y) + z |
Date: |
Sun, 06 Mar 2005 17:15:47 +0000 |
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 semantics at all? You
>may not have a classic form of symbol table, but surely some way of
>knowing what a given identifier means, don't you?
Perhaps not. My interest is in measuring the characteristics of
source code. If the number of ambiguous parses is small enough
then I can ignore their impact on the measurements.
>So you don't keep symbols between statements?
Not yet. I have been thinking about what this might buy me.
>it seems like you're trying to
>write a heuristic parser (whatever this means), and I'm not sure if
>bison or any automatic parser generator is really suitable for this.
The final grammar is likely to have several uses. Heuristic parsing
is one interesting avenue. Automatic parser generator or hand written;
it is a tough problem.
>> Good alternative suggestion. But this still requires tree rewriting
>> after the expression has been parsed. My %gooa option proposal
>> avoids this grammar violence.
>
>If I understand your previous mails correctly, it doesn't.
Changing the associativity of an operator will potentially result in a different
parse tree being generated.
> It may
>make the cases where you need to rewrite less common, but it's not
>clear that this makes your code any simpler (as you write it once,
>no matter how often it will be executed anyway).
At the moment I do not have a solution to the ambiguity present in the
token sequence:
static int (foo); static
ie a declaration and the first token from a second declaration. %gooa
would get me out of this hole without a big grammar rewrite.
derek
--
Derek M Jones tel: +44 (0) 1252 520 667
Knowledge Software Ltd mailto:address@hidden
Applications Standards Conformance Testing http://www.knosof.co.uk
- Re: Forcing multiple parse stacks to 'reduce', (continued)
- Re: Forcing multiple parse stacks to 'reduce', Hans Aberg, 2005/03/01
- Re: Forcing multiple parse stacks to 'reduce', Derek M Jones, 2005/03/02
- Re: x + (y) + z, Frank Heckenbach, 2005/03/03
- Re: x + (y) + z, Derek M Jones, 2005/03/04
- Re: x + (y) + z, Frank Heckenbach, 2005/03/04
- Message not available
- Re: x + (y) + z, Frank Heckenbach, 2005/03/06
- Re: x + (y) + z,
Derek M Jones <=
- Re: x + (y) + z, Kelly Leahy, 2005/03/04