🚀 go-pugleaf

In article <2400047@otter.hpl.hp.com> sfk@otter.hpl.hp.com (Steve Knight)
writes:
	[A much more balanced view of Algol!  But he raises a point that
I don't follow:]

>On the topic of procedural results, Andy states:
>> There is no such restriction (as I stated in my previous posting).
>He supplies this program:
	[Algol program deleted]
>This indeed shows that I overstated the restriction (whoops!).  However, the
>salient feature of this program is that the procedure is invoked within the
>scope of "x".  The restriction I was trying to capture should be extended
>to include an invocation of the procedure outside the scope of the variable it
>"captures".  [ML example 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?

	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".  This is, of course, the *default*
situation in languages that do not have scoped variables, but that is a
different argument.

	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".  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.

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