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