Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!mcnc!unc!rentsch
From: rentsch@unc.UUCP
Newsgroups: comp.lang.smalltalk
Subject: Re: Block variables
Message-ID: <12@unc.unc.UUCP>
Date: Sun, 5-Apr-87 15:49:17 EST
Article-I.D.: unc.12
Posted: Sun Apr  5 15:49:17 1987
Date-Received: Wed, 8-Apr-87 04:34:53 EST
References: <2084@mmintl.UUCP>
Reply-To: rentsch@unc.UUCP (Tim Rentsch)
Organization: CS Dept, U. of N. Carolina, Chapel Hill
Lines: 69

In article <2084@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes:
> What is the proper scope for the name of a variable which is a block
> argument?  I had assumed it was the block only, but Smalltalk/V treats it as
> the entire method.  Is this a bug?

The Smalltalk/V treatment is the same as that used by Smalltalk-80
(i.e., block argument is really a local variable in the containing
method).  The semantics of Smalltalk/V agrees with Smalltalk-80 (and
thus is arguably not a "bug").



> In UndefinedObject, define:
> 
> test
>     | x |
>     x := 3.
>     ^Array with: [ :x | x + 1] with: [x]
> 
> Now evaluate:
> 
> | temp |
> temp := nil test.
> (temp at: 1) value: 7.
> (temp at: 2) value
> 
> Should the result be 3 or 7?
> 
> (I am using ":=" as the assignment operator, as Smalltalk/V does.)

The result should be 7 by Smalltalk-80 semantics.  Here is an
equivalent, but simpler, version of the same test:

	| x |
	x := 3.
	[ :x | nil ] value: 7.
	x

(select and choose 'print it' [or is it 'show it' in Smalltalk/V?].)
Result will be 7, not 3.  (Note the "nil" returned from the block is
ignored, and the block could have been written "[ :x ]" with
equivalent effect.)

I agree, by the way, that these semantics are neither intuitive nor
particularly desireable.  This problem is magnified for nested
blocks;  consider for example

	1 to: thing xDimension do: [ :i |
		1 to: thing yDimension do: [ :j |
			(thing at: i@j) whatever: i@j ] ].

If the body of the inner loop is thought to be expensive and worth a
new process for every j (e.g., "1 to: thing yDimension parallelDo:",
etc.), the various processes will interact deleteriously because
there is really only ONE j.  (For that matter, the same comments
apply to the outer loop and i;  for some reason, I see the
non-block-structureness as a clearer example of the problem in the
inner block.)

In spite of the name, blocks in Smalltalk (either -80 or /V) do not
have block structure (either in terms of scope or in terms of
variable lifetime) as Algol-60 defines it.  It would be nice if this
deficiency could be remedied, but it is difficult given the current
Smalltalk-80 virtual machine architecture (which puts block locals
in the home context).

cheers, and Happy Smalltalking,

txr