Full Block Closure

Bijan Parsia bparsia at email.unc.edu
Sat Nov 20 01:07:58 UTC 1999


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.
>
>If anyone is working on this, I'd like to encourage them to keep at it!

As I thought about this and did some testing, I realized that I was wrong
in believing that name clashs between declared method and block temps were
caught. That's nice. But Les's problem still persists (i.e., you can end up
using a temp that isn't explicitly declared at the start of the method).
There *could* be times, if you were changing stuff around, where you'd end
missing that (i.e., if you had a complicated method (which you shouldn't :)
and moved a temp inside a block, but didn't catch all the uses of that temp
in your method, there'd be no compiler check).

So,

	[|temp| temp := 1] value.
	temp.

Will work, but it shouldn't. (Printing it gets you '1'.)

	temp.
	[|temp| temp := 1] value.

Gives the correct error.

I suppose you could always munge the block temps names so they'd be
unlikely to clash (ugh). It would be nicer to hold onto the block temps
until the entire method is parsed, and then compare the block temps to the
method temps before merging. If there are duplicates one can either signal
an error or munge the name (error is better!). Alas, I can't quite see
where to do this :(

Any pointers Craig? Anyone?

How does one grab the parse tree of a method? I.e., which method with what
arguments can one inspect the results to look parse tree? Tips?

Cheers,
Bijan Parsia.





More information about the Squeak-dev mailing list