At 12:48 AM -0500 11/20/99, Les Tyrrell wrote:

>(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,

Really? Whoa.

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

Yep. Eek!

Of course, this, I would hope, given proper style :), will be somewhat rare!

>  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

This seems right to me. The block argument shadows the method temp, just as
a method invokation that had temp as an argument would shadow the temporary
in the calling text/context.

Indeed, I would hope for that behavior for:

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

(Given block closures and lexical scoping.)

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

I didn't understand this. Can you use the t3 after the block? As a fresh
variable or does it bind the same object as the inside-the-block t3?

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

I think I've lost track of the dangers :) That is, see some, but not
exactly the one's you allude to above.

Chees,
Bijan Parsia.