Re: [MI] -stack-list-variables

[Vladimir Prus <vladimir at codesourcery dot com>]

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