[doc] improve MI varobj introduction

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Mon, 08 Jan 2007 17:49:12 +0300
> > 
> >   Variable objects are an MI convenience feature to reference
> >   expressions.  When a frontend creates a variable object, it
> >   specifies a name for an arbitrary expression in the debugged
> >   program.  That name can henceforth be used as an opaque handle for
> >   the expression.  The expression can be a simple variable, or it can
> >   be ...
> > 
> > Okay?
> 
> You're right that my text did not say why it's recommended, but I think the
> above is also not accurate. "convenient feature to reference expressions"
> is not quite right -- it sounds like varobj is just a method to create
> aliases for expression, and varobjs are much more than that. How about:
> 
>         Variable objects are "object-oriented" MI interface for
>         examining and changing values of expressions. Unlike some other
>         MI interfaces that work with expressions, variable objects are
>         specifically designed for simple and efficient 
>         presentation in the frontend. A variable object is identified
>         by string name. When a variable object is created, the
>         frontend specifies the expression for that variable object.
>         The expression can be a simple variable ........

The first two sentences sound to me more like advertisement, but if
you feel you need to say that, fine.

> >   A child variable object can itself have children, until we reach
> >   leaf variable objects which have built-in types.
> 
> That looks fine for me, but should not we have a command before "which"?
> Otherwise, it sounds like there are two kind of leaf variable objects --
> those of builtin types and those of non-builtin types.

I just tried to make a minimal modification of your text.  Perhaps a
better variant is this:

  A child variable object can itself have children, recursively.
  Recursion ends when we reach leaf variable objects that have
  built-in types.