Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

The wonderfulness of block arguments

2 views
Skip to first unread message

Michael O'Brien

unread,
Aug 29, 1986, 7:01:52 PM8/29/86
to
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
obr...@rand-unix.arpa

Jan Steinman

unread,
Sep 2, 1986, 2:43:54 PM9/2/86
to
In article <4...@randvax.UUCP> obr...@randvax.UUCP (Michael O'Brien) writes:
>If a block argument has the same name as a temporary variable, they seem
>to be the same thing...

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

Block arguments ARE temporary variables, at least from the Virtual
Machine's point of view. (The Blue Book has a good discussion of this on
pages 559-560.) The behavior cited is due to the scoping rules of the
Smalltalk compiler -- temporaries cannot be used before they are declared.
If the "[:blockArgumentName|" construct is thought of as an out-of-place
temporary declaration, the described behavior makes sense.

Block arguments are initialized to "nil", as are all temporary variables.

--
:::::: Artificial Intelligence Machines --- Smalltalk Project ::::::
:::::: Jan Steinman Box 1000, MS 60-405 (w)503/685-2956 ::::::
:::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::

0 new messages