What rules to follow to avoid block-closure problems?

I got bitten again (this time not in my seaside code) by nested blocks not
working as expected. Ouch, debugging that was painful.

Is there a *simple* rule to follow to avoid this? Should every use of nested
blocks be replaced by a self-message (with parameters for all the block
context needed) that does the same? Would be a shame, but if it guarentees
safe code I will gladly do it.

Such a rule would be useful in the Squeak FAQ (not that I've read it :-)

Thanks,

Sophie

On 1/13/08, itsme213 <[hidden email]> wrote:
> I got bitten again (this time not in my seaside code) by nested blocks not
> working as expected. Ouch, debugging that was painful.
>
> Is there a *simple* rule to follow to avoid this? Should every use of nested
> blocks be replaced by a self-message (with parameters for all the block
> context needed) that does the same? Would be a shame, but if it guarentees
> safe code I will gladly do it.

Debugging blocks can take a bit of getting used to, but once you get
how blocks work, you won't even think about it any more. And blocks
are one of the things that make Smalltalk so powerful, so they should
not be avoided by any means, imho.

Actually, stepping through some code containing blocks will probably
help you understand block closures better. Just step into the parts
where blocks are being sent to an object, and in the method "behind"
it, step over message sends until you get to the point where #value is
sent to the block. Step into that and you'll be back in the message
you started, only "inside" the block. The same principle works for
nested blocks, although obviously sometimes it can take a few more
clicks to get to where you want.

Let me know if that doesn't explain it well enough and I'll try to
come up with an example... ;-)

Cheers,

Amos

>> Is there a *simple* rule to follow to avoid this? Should every use of nested
>> blocks be replaced by a self-message (with parameters for all the block
>> context needed) that does the same? Would be a shame, but if it guarentees
>> safe code I will gladly do it.

It should.

> Let me know if that doesn't explain it well enough and I'll try to
> come up with an example... ;-)

No, it doesn't.  The OP's problem is not about "blocks" per se, it is
about blocks *not behaving as real closures*.  It's a pity that I've
seen the community discuss this issue for at least 10 years, and no
solution has been agreed upon yet.

Paolo

> The OP's problem is not about "blocks" per se, it is
> about blocks *not behaving as real closures*.

Ah, my bad - I don't believe I've come across that problem yet in my
short time squeaking. Have you got an example handy? (Yes, I know I
could search... tends to be tedious though - I take it a move to a
"normal" forum has been ruled out...)

"Amos" <[hidden email]> says:

> > The OP's problem is not about "blocks" per se, it is
> > about blocks *not behaving as real closures*.
>
> Ah, my bad - I don't believe I've come across that problem yet in my
> short time squeaking. Have you got an example handy? (Yes, I know I
> could search... tends to be tedious though - I take it a move to a
> "normal" forum has been ruled out...)

If you search for "fixTemps" in the list archives you should find many
threads on the blocks-aren't-quite-closures problem. There was one just the
other week, in fact: "3.9 vs. 3.10: Closures, fixtemps", dated 2007/12/18.

frank

"Amos" <[hidden email]> wrote in message
> Have you got an example handy?

http://wiki.squeak.org/squeak/331

> > Have you got an example handy?
>
> http://wiki.squeak.org/squeak/331

Interesting. The example on that page works just fine in VW (which is
what I'm used to), but not in Squeak. So... probably a dumb question,
but are some Squeakers seriously willing to live with that...?

>>>>> "Amos" == Amos  <[hidden email]> writes:

>> > Have you got an example handy?
>>
>> http://wiki.squeak.org/squeak/331

Amos> Interesting. The example on that page works just fine in VW (which is
Amos> what I'm used to), but not in Squeak. So... probably a dumb question,
Amos> but are some Squeakers seriously willing to live with that...?

But this works fine as well in modern VMs:

|blocks|
blocks := (1 to: 10) collect: [:each | [each] fixTemps].
blocks first value.

The point is that BlockContext>>#fixTemps is (a) a hack (doesn't work EVERY
time) and (b) expensive, so it isn't sent every time, even though that
probably wouldn't hurt.

For now, it's up to you to know when you have a block that might need closure
treatment, which is simple enough to determine by humans: do you need the
values of externally defined temps to be cloned and disconnected from the
surrounding code?  In this case, the answer was "yes", because we wanted each
block to have its own "each" temp.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

"Randal L. Schwartz" <[hidden email]> wrote in message

> But this works fine as well in modern VMs:
>
> |blocks|
> blocks := (1 to: 10) collect: [:each | [each] fixTemps].
> blocks first value.

I think #fixTemps fixes block-closure shortcomings only for some cases. e.g.
I had posted an example recently that failed despite #fixTemps. Hope it
won't stay this way for too much longer ...

Sophie

>>>>> "itsme213" == itsme213  <[hidden email]> writes:

itsme213> I think #fixTemps fixes block-closure shortcomings only for some
itsme213> cases. e.g.  I had posted an example recently that failed despite
itsme213> #fixTemps. Hope it won't stay this way for too much longer ...

Did you miss the part where I said:

"The point is that BlockContext>>#fixTemps is (a) a hack (doesn't work EVERY
time) "

Please read more carefully next time.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

"Randal L. Schwartz" <[hidden email]> wrote in message

> Did you miss the part where I said:
>
> "The point is that BlockContext>>#fixTemps is (a) a hack (doesn't work
> EVERY
> time) "
>
> Please read more carefully next time.

I was simply pointing at an actual example where fixTemps did not work. No
offense intended :-)

Sophie