(oops- should have checked that more carefully )

Actually, the problem that I had meant to point out was that block ARGUMENTS
appear to become method temporaries, again without being listed as such in the
source of the method,  and ( as you point out ) they can then be used as variables after
the block in which they are used.  I came across this in two of the methods in the
compiler framework.

VisualWorks will allow you to use the same name for a method temp and a block argument,
but it will notify you about the conflict before it does that.  The result may look the same,
but in fact it appears that something else is done internally- for example, a method such as:

    checking
     | block temp |
     block := [ : temp | temp ].
     ^ temp.

in VisualWorks will become: ( after invoking the decompiler through a shift-select of the selector )

    checking
     | t1 t2 |
     t1 := [ : t3 | t3].
     ^ t2

On a file-in, if the variable 'temp' had not been listed in the method temporaries then it would
go straight to undeclared, without notifying the user about anything- so now a bad situation
becomes even worse as the same value gets shared across method invocations.  Now that
I'm looking at this, I feel that VW ( and Smalltalk in general ) should flat-out refuse to compile
a method like the above- you can't count on an interactive dialog with auser/programmer
to always highlight the dangers that the original programmer might have been willing to accept.

-les

----- Original Message ----- 
From: Bijan Parsia <bparsia at email.unc.edu>
To: <squeak at cs.uiuc.edu>
Sent: Friday, November 19, 1999 7:07 PM
Subject: Re: Full Block Closure


> At 11:07 PM -0500 11/18/99, Les Tyrrell wrote:
> 
> >But unfortunately it also allows that same variable to be used before and
> >after the block
> >in which it appears
> 
> Only after, acutally.
>
> >, without that variable appearing within the method's temporaries list.
> >Hopefully, people seeing examples of this will not assume that it is
> >correct Smalltalk.
..