Re: [RFA] Have block_innermost_frame start from selected frame

[Paul Hilfinger <Hilfinger at adacore dot com>]

> > @@ -7304,12 +7304,13 @@ examine the variable @code{b} while your program is executing inside
> >  the block where @code{b} is declared.
> >  
> >  @cindex variable name conflict
> > -There is an exception: you can refer to a variable or function whose
> > +You can refer to a variable or function whose
> >  scope is a single source file even if the current execution point is not
> >  in this file.  But it is possible to have more than one such variable or
> >  function with the same name (in different source files).  If that
> >  happens, referring to that name has unpredictable effects.  If you wish,
> > -you can specify a static variable in a particular function or file,
> > +you can specify a static variable in a particular function or file by
> > +qualifying its name
> >  using the colon-colon (@code{::}) notation:
> >  
> >  @cindex colon-colon, context for variables/functions
> 
> This hunk seems to be limited to changes in style, rather than
> content.  Can you tell why you thought these style changes are needed,
> in particular the first one?
> 
> Also, I have reservations about using the term "qualifying" for this
> notation.  Since we already use "scope resolution" for them in the C++
> context, why not use "scope resolution" for C and other languages as
> well?
> 

I'm not wed to these changes.  The first one is accidental: I had wanted to
modify the section so that first it talked about unqualified uses and then 
turned to qualified uses, not as an "exception" but rather as a separate case.
Apparently, I neglected to modify the preceding portion to specifically say it
concerned unqualified variables.

The second change was to introduce the term "qualified".  However, it also
corrects a slight problem---that comma after "file," is out of place, I think.
However, if you don't like "qualifying", I am happy to remove both changes.

> > +unqualified name of the variable.  However, you may also use this notation
> > +to refer to local variables in frames enclosing the selected frame:
> 
> I'm not sure "enclosing frame" is clear enough.  I think we tend to
> use "outer frame" elsewhere in the manual.  Alternatively, you could
> use "enclosing scope".
> 

Yeah, but I really need to say something like "frames that are at or outside
the selected frame".  Would that be understandable terminology, do you think?

I don't like "enclosing scope".  We are dealing with statically scoped
languages, where "enclosing scope" usually means "lexically enclosing
scope", and that is not what we are talking about here.

> > +@smallexample
> > +(@value{GDBP}) p a
> > +(@value{GDBP}) p bar::a
> > +(@value{GDBP}) up 2
> > +(@value{GDBP}) p a
> > +(@value{GDBP}) p bar::a
> > +
> > +@end smallexample
> 
> Please remove the empty line before "@end smallexample".

Right.

> Anyway, this begs the question: is the scope resolution available only
> for print commands, or also in other commands, like `watch'?  If the
> latter can also use this, then I think we should mention that, here
> and where watchpoints are described.  If the `watch' command cannot
> use this, then it sounds like we are inconsistent here.
> 
Well, since I don't see any circular arguments here, I wouldn't say
that any questions are being begged [sorry: obligatory pedantry
there], but you are certainly right that it does raise the question of
general applicability.  The section is about "Program variables" but
all examples use 'print'.  Furthermore, you are correct that watch
behaves incorrectly at the moment: it picks up the correct variable
value when 'watch' is issued, but then reverts to the old behavior
when deciding which variable to watch, giving nonsensical results.  I
will have to revise the patch.  Thanks for catching this.

-- 
Paul N. Hilfinger
(Hilfinger@adacore.com)