🚀 go-pugleaf

Dr A. N. Walker says:

   In article <KERS.91May13165106@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com
   (Chris Dollin) writes:
   >Dr A. N. Walker responds to Steve Knight:
	   [much deleted]
   >					    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.

	   Yes he has!

   >Just because x would go out of (lexical) scope need not mean that its 
   >store has to be reclaimed.

	   From time immemorial, whatever the equivalent of

		   BEGIN REAL x; ... END

   is in your favourite Algol-based language has meant something like

		   start a new stack frame, allocate some *local* space for a
		   real variable identified by "x", ..., deallocate the space
		   and close the frame.

We have a difference of opinion here. *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)''. The stuff about stack frames is just an
implementation technique which works very well so long as you can't export some
sort of reference to (the item named by) x - as was the case in Algol 60, but
not in Algol 68.

We can argue about what languages are ``Algol-based'', and quite when ``time
immemorial'' started and finished, but above description does not apply to ML,
or PAL, or SASL (or KRC, or Miranda), or Scheme, or Common Lisp.

Dr. Walker continues (quoting me again):

   >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)?

	   Arguably, but I don't think so.  Composition is a reasonable
   thing to want, but using a variable out of scope isn't.  (Note: "scope"
   in Algol is a technical term, and differs from "range", which seems to
   be what some contributors mean by "lexical scope".)  Reasonable wants
   shouldn't be satisfied in unreasonable ways.

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. (Clearly, you *cannot* use something that's gone
``out of scope'' in the Algol68 sense - it ain't there. But I think the other
contributors mean ``lexical scope'', aka ``range'', by scope. Certainly that's
what Steve means [the observant reader will note that we post from the same
site, and in fact we regularly discuss issues such as this, so I have a fair
idea of what he means!].

	   It is true if you try to write composition in the obvious way
   the result has a uselessly narrow scope.  The partial parametrisation
   proposals [see Algol Bulletin #37, p24] get around this without
   putting unreasonable loads on the implementation, but within the
   spirit of the scope rules.  This possibility shows that composition
   weaknesses aren't a necessary consequence of tight scope rules.

If you can implement partial parameterisation, you can implement full lexcial
scope (ie, indefinite scope for locals used in exported procedures) using it.
[Proof by example: that's how Poplog Pop11 does lexical closures.] Hence
there's no reason not to make (eg) composition have full Algol68-scope if you
have partial parameterisation.






--

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