Quinn Dunkan <quinn / envy.ugcs.caltech.edu> writes:

> >      Global variables are available throughout an
> >      application. Reference to an uninitialized global variable
> >      returns nil.
> > 
> >      Instance variables are available throughout a class
> >      body. Reference to an uninitialized instance variable returns
> >      nil.
> 
> You mention that an uninitialized {global,instance} variable evaluates to nil
> (I'd say "evaluates to" rather than "reference to returns"), and so for
> symmetry you should probably mention that evaluating an uninitialized local
> variable throws a NameError.

Good point.

> > Normally I'd agree, but this section is entitled "Scope of Variables", 
> > so I was trying hard (and failing later on) not to define scope in
> > terms of scope.
> 
> Then you should probably define scope *before* you go on to describe ruby's
> (somewhat complicated) idea of scope.  Scope is a simple concept that turns
> out to have deep ramifications, but if you define the word first then you can
> use the standard terminology to describe the ramifications.

The problem is with local variables, which have two kinds of scope
(static namespace scope and dynamic availability scope). I started off 
trying to define scope in an original version, and gave up and went to 
the definition-by-example stuff I posted. Am I making this too
difficult. Is there a tody definition of scope I could use up front?

Ever hopeful,


Dave