Re: MI: type prefixes for values

[Vladimir Prus <ghost@cs.msu.su>]

On Friday 17 February 2006 21:59, Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Fri, 17 Feb 2006 17:24:03 +0300
> > Cc: gdb@sources.redhat.com
> >
> > > > - The parsing of that value will have to be done by ad-hoc code,
> > > > which is contrary to MI-goal of being easily parsable.
> > >
> > > Why ad-hoc? if you have {}, parse it, if not, don't.  Why is this
> > > simple rule hard for a parser?
> >
> > Here's the relevant part from KDevelop:
> >
> >   if (*start == '{')
> >     {
> >         // Gdb uses '{' in two cases:
> >         // - composites (arrays and structures)
> >         // - pointers to functions. In this case type is
> >         //   enclosed in "{}". Not sure why it's so, as
> >         //   when printing pointer, type is in parenthesis.
> >         if (type == typePointer)
> >         {
> >             // Looks like type in braces at the beginning. Strip it.
> >             start = skipDelim(start, '{', '}');
> >         }
> >         else
> >         {
> >             // Looks like composite, strip the braces and return.
> >             return QCString(start+1, end - start -1);
> >         }
>
> I'd never suspect that someone would try to parse MI with such
> ad-hoc'ish code.  I assumed that a decent parser was being used, and
> that this parser could simply choose the right template--either the
> one for response with braces, or the one for without.
>
> With such one-character-at-a-time parsing of MI's output, I now
> understand why you want MI to talk in small chunks.  This code is okay
> for parsing irregular streams such as what CLI produces, but that's not
> the right way of dealing with structured data streams such as the one
> produced by MI.  You need a fairly general-purpose reader that would
> create a data structure for what it reads and populate the structure's
> members with what it finds in MI's output.  Then you just pluck
> whatever you need from that data structure.
>
> I really don't think that we should cater to such ``parsers''.  They
> need to be thrown away and rewritten, IMO.

Eli,
I'm disappointed by you making such broad statements based on no data. 
Had you looked at code:

   http://websvn.kde.org/branches/work/kdevelop-debugger-mi/mi/
   http://websvn.kde.org/branches/work/kdevelop-debugger-mi/mi/gdbmi.h?rev=504799&view=markup

you'd notice that a data structure is being created. And as I've already said in this thread:

   http://article.gmane.org/gmane.comp.gdb.devel/15652

the "breace-removing" code is specifically for removing uncessary data from "value" literals, which 
have no formal grammar.


> > You see, if I strip everything {}-enclosed at the beginning of value,
> > I'll never show any structures. And how do I decide if the value is a
> > pointer, or structure?
>
> The same way a compiler's parser decides: by writing code that checks
> the text against several templates and finding the one that matches.
> I believe people who defined and implemented MI intended for its
> output to be structured so that it could be easily parsed, but you
> need to write a parser that knows how to deal with structured text.
> Take a look at an XML parser, for example, or at a Lisp reader.

Can you please avoid giving generic advice about writing parsers?

> That's how you should deal with this, IMO, not by looking at each
> individual character in turn and trying to decide, based on that
> single character, what could that mean.

I belive you're missing something. The *formal grammar* 
of MI is actually LL(1), so it can be parsed exactly by looking 
at one next character and deciding what to do. 

> > > > > Then perhaps we should add the type info to all arguments, instead
> > > > > of removing it from where it exists now.the writers
> > > >
> > > > It might be good idea, but why don't add it as a separate field? I.e.
> > > > instead of
> > > >
> > > >   ^done,value="(int *) 0x0"
> > > >
> > > > you'll get
> > > >
> > > >   ^done,value="0x0",type="int *"
> > >
> > > Fine with me.
> >
> > So, are patches to the effect of removing type from value, and moving it
> > to a separate field welcome?
>
> I won't object.  But I still think you need to replace that parser.

I think not.

- Volodya