Re: GDB/MI Output Syntax

[Michael Chastain <mec dot gnu at mindspring dot com>]

Well, the difference betwen:

  # more nonterminals
  async_record        : exec_async_output | status_async_output | notify_async_output ;
  exec_async_output   : opt_token "*" async_output ;
  status_async_output : opt_token "+" async_output ;
  notify_async_output : opt_token "=" async_output ;

And:

  # less nonterminals
  async_record      : opt_token async_record_kind async_output
  async_record_kind : "*" | "+" | "="

... that difference is not going to make-or-break the necessary
LALR(1) property.  The place to watch out for that is with
rules that can be reduced with 0 input tokens.  That gets ambiguous
real fast.

My esthetics say to combine common things, Andrew's esthetics
say to be more concrete names for things.  It's an esthetic tradeoff.
Andrew has more say as the MI maintainer.

exec_async_output is actually a pretty good nonterminal.  It's
async_output that really bugs me.  async_output is not a complete
object, it's a sub-part that doesn't really need to be there.
Just substitute in its definition.

> 	async-result ==> async-class ( "," @var{result} )* @var{nl}

I think the "*" stuff has to go, though.  bison and yacc don't process
it.  Which means that as soon as someone tries to write a bison grammar,
they have to write something different from our doco.  So every front
end will have a slightly different parser and that will be to GDB's
sorrow.  Eventurally GDB will do something that's in the printed
grammar, and some front end will tip over because it's not accepted by
their bison grammar.

Also, some front-end writers will walk into the same sand-trap that
Bob did when they are translating (a b)* into bison language,
and mistakenly write a non-LALR(1) grammar.

The closer our doco is to a real bison grammar that really compiles,
the less grief.

bob> The reason it would be helpful to modify the grammar in this way is that
bob> it leads to a more elegant form when trying to build an intermediate
bob> representation. At the parse level of 'stream-record' or 'async-record'
bob> you have all of the information necessary in order to populate a
bob> structure with data. Otherwise, the information is a few levels down
bob> stream.

ac> I don't follow.

Every time a yacc/bison rule is reduced, the code associated with that
rule has to make another data structure that copies/refers-to all the
data from each of the components.  So a flatter rule tree means
the C code looks like "a->b->data" instead of "a->b->c->d->data".