Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!hplabs!tektronix!tekcrl!tekchips!allenw
From: allenw@tekchips.UUCP (Brock)
Newsgroups: net.lang.st80
Subject: Re: The wonderfulness of block arguments
Message-ID: <612@tekchips.UUCP>
Date: Tue, 2-Sep-86 12:42:28 EDT
Article-I.D.: tekchips.612
Posted: Tue Sep  2 12:42:28 1986
Date-Received: Wed, 3-Sep-86 18:42:42 EDT
References: <492@randvax.UUCP>
Organization: Tektronix, Inc., Beaverton, OR
Lines: 67
Keywords: arguments
Summary: Block arguments semantics explained


> I've been noodling around the hierarchy for some time now, and have come
> across one really peculiar construction that doesn't seem to be mentioned
> anywhere, but which seems to work reliably.  It seems to be a sneaky way
> to pass a pointer to a temporary variable (at least) as well as several
> other things.
> 
> If a block argument has the same name as a temporary variable, they seem
> to be the same thing:
> 
> | foo |
> foo _ 1.
> [:foo] value: 3.
> foo _ foo + 1
> 
> This evaluates to 4, not 2.  In particular, if the block [:foo] is handed off
> as the argument to a message selector, that other method can change the value
> of "foo" seen on return in the local method.  This is used in the file system
> code, at least.
> 
> Also, block arguments which are uniquely named are still available after the
> block returns (but not before!).  Hence,
> 
> [:fum] value:3.
> fum _ fum + 1
> 
> is legal and returns 4.  However,
> 
> fum _ fum + 1.
> [:fum] value:3
> 
> won't compile.
> 

Block arguments are ALWAYS represented as method temporaries of the block's
home context.  The use of a symbol as a block argument implicitly declares
it to be a method temporary.  Following such an implicit declaration
the variable may be used as if it had been explicitly declared.  All occurences
of a variable name within a method (and any contained blocks) refer to the
same storage location.

> It is entirely possible that there is some punning going on, and that if the
> block is not evaluated, the block argument will refer to some other variable
> or to random storage.  I don't know enough about the compiler to say.  Still,
> it seems mightily peculiar, if sometimes useful.
> 
> Comments?
> -- 
> Mike O'Brien
> The Rand Corporation
> 
> {sdcrdcf,decvax}!randvax!obrien
> obrien@rand-unix.arpa

The standard compiler and virtual machine always allocates space for block arguments
in the temporary frame of the enclosing method context.  Evaluation of a block
will not effect the existance of the storage for its arguments, only what values they
contain. (All variables are initialized to nil)

In general the semantics of block arguments are poorly defined by the Smalltalk language
"definition" and the semantics which are implicitly defined by the standard implementations
have a number of ugly implications (for example, blocks are not reentrant and hence not
recursively callable).  This is an area where Smalltalk-80 could use some major design
cleanup.

				Allen Wirfs-Brock
				Tektronix, Inc.