Re: MI: type prefixes for values

[Eli Zaretskii <eliz@gnu.org>]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Fri, 17 Feb 2006 16:58:22 +0300
> Cc: gdb@sources.redhat.com
> 
> > > It's only avaiable in tooltip text for a variable. So far, no complaints.
> >
> > I don't see how is this contrary to what GDB assumes.  GDB passes the
> > information to the front end; how the front end displays it, is
> > entirely up to the front end.
> 
> Because for display in variable tree, frontend prefers not to show any type,
> and for display in varible tooltips, it prefers to show the type after the 
> value, not before.

That's quite specific to that front end, right?  We cannot possibly
assume they all will behave like that.

> > > In the output of print, the type of variable is sometimes wrapped in
> > > {}, sometimes in (), and there are no formal rules a frontend author
> > > can use to extract type from this information.
> >
> > The formal rules can be stated, if that's what is missing.  The code
> > that produces the parentheses is deterministic, so the rules for when
> > they are used can be defined.
> 
> Sure, they can be stated. But:
> - I don't think anobody is working on that

Volunteers are welcome.

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

> > Then perhaps we should add the type info to all arguments, instead of
> > removing it from where it exists now.
> 
> 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.