🚀 go-pugleaf

Dr A. N. Walker responds to Steve Knight:

   In article <2400047@otter.hpl.hp.com> sfk@otter.hpl.hp.com (Steve Knight)
   writes:
[deleted]

	   The procedure that is being delivered is "(REAL a) REAL: x + a",
   in which "x" is a real variable declared somewhere else.  In a scoped
   language, how can this procedure even be contemplated except while "x"
   is still in scope?  The pseudo-instruction "throw away x, it's now gone
   out of scope" is incompatible with a later pseudo-instruction "grab the
   value stored in x and add it to a".  Thus, the scope of the procedure is
   *inevitably* tied up with that of "x".  If you want your procedure to
   work, you mustn't tell the computer to throw away "x" first!  But this
   seems to be what Steve wants.  Or have I misunderstood something?

This is what Steve wants; he *hasn't* told the computer to throw anything away.
Just because x would go out of (lexical) scope need not mean that its store has
to be reclaimed.

	   You could always declare "HEAP REAL x" to give "x" global scope,
   and then your procedure would work anywhere, even in parts of the program
   that couldn't refer directly to "x".  

I had this vague recollection that this still wouldn't work in Algol68; you can
give x global scope, but theres some intrinsic local required to refer to it,
and the defining document doesn't let you export *that* out of x's scope. But I
can't give details.

    This is, of course, the *default*
   situation in languages that do not have scoped variables, but that is a
   different argument.

Which languages were you thinking of that ``do not have scoped variables''?
Perhaps (from the context of the discussion) you were intending to denote Lisp,
ML, or Scheme (or even Pop11!), but they all have what *I'* call scoped
variables. [In, for contrast, Pascal or C, the question hardly arises; either
there are no nested procedures, or the restrictions on their export are 
draconian.]

   This "restriction" is not, as Steve initially suggested, something
   unorthogonal and peculiar to procedures;  it applies equally to, for
   example, pointers, and any other objects that might want to use "x".

That's true (but it's still a restriction, not a "restriction").

   I still suspect
   that Steve is *really* thinking of something different, namely the effect
   of procedure *parameters*, which make functional composition less useful
   in Algol than one might hope;  I won't bore readers further with either
   the problem or its proposed solutions, which have been well rehearsed in
   this newsgroup in the past.

Isn't the latter (weakness of A68 functional composition) just a consequence of
the former (can't export a procedure outside the scope of one of its free
variables)?
--

Regards, Kers.      | "You're better off  not dreaming of  the things to come;
Caravan:            | Dreams  are always ending  far too soon."