Re: x + (y) + z

[Frank Heckenbach]

(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 also mentioned in another
> >mail) may be an option, but IMHO not a very good one, if you can't
> >use the parser the way it's supposed to.
> 
> These things are sometimes necessary.  My lalr(1) grammar of C
> changes the tree built for parameters from infix to postfix (or maybe
> the other way around; I don't have the source to hand).
> 
> >But since you don't state why you don't do the usual thing (separate
> >token for type names), I can't say anything more ...
> 
> 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?

> Because I don't have a symbol table to look things up in.
> Perhaps I should have pointed this out (it also answers
> Frank Heckenbach's question).  When parsing the visible
> source (ie not doing any preprocessing; well apart from
> ignoring the directives) a statement/declaration at a time
> the content of a symbol table are likely to be very incomplete.

So you don't keep symbols between statements? Then what is your
program supposed to output at all? Some token sequences are
ambiguous, if you don't know e.g. if some identifier is a type or
not. So it seems the best you could output then is "there are two
alternatives: ... and ...". This would look like the `%merge'
example in the manual, so maybe you can use `%merge'.

Otherwise, if you want to output "This means probably this: ...",
and not mention the alternatives, 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.

> 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. 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).

Frank

-- 
Frank Heckenbach, address@hidden
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)