Re: [MI] -stack-list-variables

Vladimir Prus
2009-09-21T07:39:30Z

On Monday 21 September 2009 Nick Roberts wrote:

> > That's only the "origin" of the values. Inside the function, parameters and locals
> > obey exactly the same rules.
>
> If you are trying to understand how a variable gets a value then you're interested
> in the origin of that value.
>
> > > If the front end doesn't care, it can always group these together.
> >
> > I was saying that all frontends I know do not seem to care, therefore it
> > does not seem like we should care.
>
> I don't really know what other frontends do but it appears useful to me.
>
> > > > Even
> > > > if we decide this information is necessary, would it not be better to present it
> > > > like this:
> > > >
> > > > ^done,variables=[{name="i", arg="1"},{name="asdf"}]
> > > >
> > > > as this format is more extensible in case some other frontend might need
> > > > even more finer details?
> > >
> > > I don't see how this helps. Breaking locals and args down further would require
> > > a new command for backward compatibilty reasons.
> >
> > Why? You can always add new field, e.g.
> >
> > ^done,variables=[{name="i", truly-magic-kind-of-symbol="1"},{name="asdf"}]
>
> Perhaps I misunderstood. I thought you mean't a third kind of local, whatever that might
> be, but we could equally add a new field like this too:
>
>
> ^done,variables={args=[{name="i", truly-magic-kind-of-symbol="1"},{name="j"}],
> locals=[{name="asdf"},{name="m"},{name="zxcv"},{name="qwert"}]}

So, those general approaches are essentially equivalent in their expressive power?
In which case, it seems reasonable to pick the approach that more directly correspond
to what current frontends need, namely a flat list of variables. Should a frontend
appear that will want to explicitly show args/locals distinctions, we can also
add the necessary field. So, we're open for future extensibility, without immediately
introducing syntax that no frontend might ever end up needed.

- Volodya