Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!news.uu.net!mcsun!ukc!warwick!nott-cs!piaggio!anw From: anw@maths.nott.ac.uk (Dr A. N. Walker) Newsgroups: comp.lang.misc Subject: Re: Algol68 (and standards diatribe) Message-ID: <1991May22.142316.11622@maths.nott.ac.uk> Date: 22 May 91 14:23:16 GMT References: <5809@goanna.cs.rmit.oz.au> Reply-To: anw@maths.nott.ac.uk (Dr A. N. Walker) Organization: Maths Dept., Nott'm Univ., UK. Lines: 116 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@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