Re: MI: type prefixes for values

[Eli Zaretskii <eliz at gnu dot org>]

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

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

> That code was written before me, and is 100 lines in size.

My advice is to throw it out and write a new one.  It is not suitable
for working with GDB/MI.

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