Re: asynchronous MI output commands

[Bob Rossi <bob_rossi@cox.net>]

> > Hmmm. That's interesting, I was hoping to not need to know what the
> > input command was in order to parse and build an ADT for the output. In
> > general, I think it would be appropriate if the MI output described
> > itself well enough that no other information was needed to understand
> > it, including the MI intput command.
> 
> What do you mean, in this context, by an ADT (and what does it mean to
> you)?  And what information do you want to represent in your parse
> result?  I think I need to understand what you want to get out of this
> data a little better.

OK. I start with the MI output. I use bison to convert that into an
abstract parse tree. Now, I am working on a solution to take the
abstract parse tree and turn it into a simple to use representation for
the front end (ADT). I gave the example earlier, taking the abstract parse
tree for -file-list-exec-source-file 
  ^done,line="26",file="test.c",fullname="/home/bob/cvs/cgdb/cgdb.mi/builddir/test.c"
and turn that into
  struct file_list_exec_source_file
  {
    int line;
    char *file;
    char *fullname;
  };
  struct file_list_exec_source_file result = { 26, "test.c", "/home..."};
  
My goal is to do this for each MI output command. I would also like to
make sure the manual reflects all the current MI commands, with the
appropriate fields, and at the end, generate the documentation from this
simple program (with ELI's help). BTW, this is all before I even try to
implement the MI implementation into my front end, so that others can
benefit from this work. Having a LISP or XML output from this program
would be trivial and I'm sure would help others down the road.

> It seems to me that most of the work of an MI parser is in converting
> the RESULT rule to some more useful tree-like structure.  

Yes, this is already done.

> You don't
> need to know what the data is to do that.  If you want to create
> individual response structure types for each supported MI command, then
> you ought to know what command is being answered (see my mail a moment
> ago for why), and be able to convert the _abstract_ tree into an
> appropriate _concrete_ structure.

Yes, I agree, if I knew the MI input command, I could use that to
determine what type of command I was looking at. If I won't be allowed
to add the command to the output record, then this is what I will do.

However, I would like to be able to do this with out knowing the MI input 
command. First, it makes the code more modular that takes the MI output
and turns it into something meaningful. Second, it's easy to gather a
bunch of MI output commands from the test suite or from FE user's with
FE problem, and parse just that output. Third, it validates that what
the user requested is what the user is getting. It is possible that the
FE and GDB could get mixed up I'm assumming.

Anyways, Daniel, thanks for taking time out of your busy schedule to
think about this issue. If you simply don't want something like this in
MI right now, I'll find a way to match the input with the output.

Bob Rossi