Re: GDB/MI Output Syntax

[Bob Rossi <bob at brasko dot net>]

On Thu, Aug 26, 2004 at 05:12:01PM -0400, Andrew Cagney wrote:
> >Hi,
> >
> >Along with the newline changes, there are 2 other changes that I propose
> >to the grammar. They are,
> >
> >async-record   ==> exec-async-output | status-async-output | 
> >notify-async-output
> >exec-async-output    ==> [ token ] "*" async-output
> >status-async-output  ==> [ token ] "+" async-output
> >notify-async-output  ==> [ token ] "=" async-output]
> 
> FYI, these were done this way so that the complete structure and intent 
> was clear (rather than worry about language issues).  As you note a 
> rewrite gives an ll(1) grammar; it also looses that clarity.

Yes, clarity is very important. Honestly, Michael helped me get the
original grammar to be ll(1). The only problem with the original grammar
that I have found so far is that it is missing a 'nl' on one line.

I only propose rearranging the gramar a little, written in the way
that it is in the doco. Also, I propose that the grammar Michael and I
are working also get posted, and say that it is a dirivative of the
original. Both ways of posting the data are helpful to front end
developers.

The only change to the original grammar I am interested in is to match
the names/rules to be similar to the grammar that Michael and I are
generated (loosing productions we have eliminated, adding productions
that we added, ... ). Either way, I think it would be helpful to say, 
here is the grammar, and here is the bison input to the grammar.

In the end, it's up to you guys.

> >The second change is identical but refers to the rules of
> >   stream-record ==> console-stream-output | target-stream-output | 
> >   log-stream-output
> >   console-stream-output ==> "~" c-string
> >   target-stream-output ==> "@" c-string
> >   log-stream-output ==> "&" c-string
> >
> >to
> >   stream-record => stream-record-kind c-string
> >   stream-record-kind => "~" | "@" | "&"
> >
> >The reason it would be helpful to modify the grammar in this way is that
> >it leads to a more elegant form when trying to build an intermediate
> >representation. At the parse level of 'stream-record' or 'async-record'
> >you have all of the information necessary in order to populate a
> >structure with data. Otherwise, the information is a few levels down
> >stream.
> 
> I don't follow.

This may not interest you at all. However, with the rules,
   > >   stream-record ==> console-stream-output | target-stream-output | 
   > >   log-stream-output
   > >   console-stream-output ==> "~" c-string
   > >   target-stream-output ==> "@" c-string
   > >   log-stream-output ==> "&" c-string

when bison get's to stream-record, it doesn't have available to it the 
c-string data. So, I can't do 
   stream_record: stream_record_class CSTRING {
       $$ = malloc ( sizeof ( struct stream_record ) );
       $$->stream_record = $1;
       $$->cstring = strdup ( gdbmi_text );
   };

With the rules,

   > >   stream-record => stream-record-kind c-string
   > >   stream-record-kind => "~" | "@" | "&"

I can do the above code, which is nice.

I understand there is other ways to do the same thing, however, this
seems elegant to me.

Thanks,
Bob Rossi