Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!caip!sri-spam!parcvax!hplabs!sdcrdcf!randvax!obrien
From: obrien@randvax.UUCP (Michael O'Brien)
Newsgroups: net.lang.st80
Subject: The wonderfulness of block arguments
Message-ID: <492@randvax.UUCP>
Date: Fri, 29-Aug-86 19:01:52 EDT
Article-I.D.: randvax.492
Posted: Fri Aug 29 19:01:52 1986
Date-Received: Sun, 31-Aug-86 09:03:48 EDT
Reply-To: obrien@randvax.UUCP (Michael O'Brien)
Organization: Rand Corp., Santa Monica
Lines: 44
Keywords: arguments

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.

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