🚀 go-pugleaf

In article <5809@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au
(Richard A. O'Keefe) writes:

>(1) BEGIN REAL x; ... END
>    opens a new environment extending its lexically enclosing environment
>    allocates some space 
>    adds a binding (x->the new space) to the new environment
>    ...
>    closes the environment
>(2) Space is reclaimed when the last reference to it goes away.

	Well, I've just checked several of my old texts on Algol 60, and
I haven't found anything that even remotely resembles that.  ("Binding"?
"Environment"?  "Reference"?)  I haven't found a text that distinguishes
in any way, let alone adequately, between variables, the storage that
they occupy, and the identifiers that identify them.  I checked my books
on Pascal and C (and others) with similar lack of success.  Plenty of
stuff about how "x" can only be used between the "BEGIN ... END", about
name hiding, sometimes about stacks.  Even some of the books on Algol 68
are distinctly hazy about all this.  [I'm pleased to say that Lindsey &
van der Meulen and Brailsford & Walker both have explanations that still
make sense to me, though I wouldn't have written either of them that way.]

	Using a modern perspective in an attempt to describe what 20-30
year-old languages were thinking about is at best anachronistic, and
almost certainly misleading.

>However, "since time immemorial", the lambda calculus has permitted the
>capture of outer variables in results:
>	(\x. \y. + y x)(3)
>returns a function equivalent to \y. + y 3.

	Irrelevant to the semantics of Algol-like languages.  Maths has
always been cavalier about scope and range of notation.

>Remember that the Algol 68 statement
>	( REAL x = 3.2 ; ... )
>need not (and in actual implementations may well not) allocate ANY
>storage for x.

	Yes, but not the example given.  *My* example has an equivalent
in every Algol-based language I know of, and is generally understood
(misunderstood, if you insist) to mean what I said.

[Algol 60 example deleted]
>						Here the inner block
>is using the variable x at a point where its name isn't visible.  All
>that going out of scope means is that the name becomes invisible and
>remains invisible.  Why is it ok to continue to use a variable in one
>case but not the other; why is not having a visible name venial in one
>case but deadly in the other?

	Because there is a difference between the identifier going out
of range [which you call "scope", and some contributors have called
"lexical scope"] and the variable it identifies going out of scope
["dynamical scope"].  Your example has "x" out of reach, but within
range and within scope, which is fine.  More interesting examples have
variables within scope after an associated identifier is out of range.

In a related posting, <KERS.91May17090215@cdollin.hpl.hp.com>,
kers@hplb.hpl.hp.com (Chris Dollin) writes:

>				       *I'd* say that the (equivalent of) the
>above code means ``once you hit END, I no longer wish to be able to use the
>name "x" to refer to ... er ... whatever it did refer to (ie, the variable, or
>the location, or the value, etc)''.

	Yes, I might say that too, but when [historically, this is not an
attempt to discover your age!] would you *first* have said that?  Before
Algol 68, there was little distinction made between "x" the identifier
and "x" the variable inside the computer [at least in the books I read].

	Even a decade later, I read in "The C Programming Language --
Reference Manual":  "... two attributes of the identifier:  its storage
class and its type. ... the type determines the meaning of the values
found in the identifier's storage.  ... Automatic variables are local
to each invocation of a block, and are discarded upon exit from the
block" [p3], "If the [storage class]-specifier is missing from a function,
it is taken to be auto inside a function" [p11], "If any of the identifiers
in the declaration-list were previously declared, the outer declaration
is pushed down [! ANW] for the duration of the block" [p16].  Pretty much
what I said!

	Again judging from books on my shelves, few other authors of books
on C, Pascal or other languages are as concise or as accurate as Dennis
Ritchie.  My conclusion is that the vast majority of authors, and hence
of lecturers and students, and hence of practitioners, espouse a very
simplistic view of scopes, lifetimes, extents, ranges, call them what
you will.  Contributors to c.l.m are self-selected to be (relatively)
knowledgeable about such things.

>Yes, it occured to me that there was a terminological problem, and that Algol68
>(for some arcane reason) used ``scope'' to mean what was usually called
>``extent'' if it was called anything, and then had to introduce a new word to
>mean what ``scope'' meant.

	I asked a few friends in the local CS Dept;  none of them had any
idea what I might mean by "extent".  Their definitions of "scope" were as
garbled as you might expect from the above.  They fared better when I asked
about "lexical/dynamical scope".  Having been bitten once or twice in the
early 70's, I have since tried [not always successfully] to use "scope",
"range", "reach", "environ" and other technical words in the Algol sense,
to explain [eg "range" == "lexical scope"] the notation when first used,
and to be prepared to interpret other usages.  That the notation is not
more widely understood seems to me to be just another example of an Algol
feature that was ahead of its time.

>							 But I think the other
>contributors mean ``lexical scope'', aka ``range'', by scope. Certainly that's
>what Steve means [...]

	That's what I assumed Steve meant first time, and what he denied.

-- 
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk