There's a preference (I can't recall the name but it's something like "allow block argument assignment"; I'll try to find it for you when I get back to the computer. Anyhow enabling this preference is there for backwards compatibility with old code that assigns to block args.

If you're writing new code, it's best to just disable the preference. This way an error will be signaled when attempting to assign to block arguments, such that you'll start getting used to working around this "limitation."

Closures give you a lot, and you won't ever truly *need* to modify a block arg. There's always another way to do it.

I won't try to go to deep into closure semantics, but if you do feel you'd like to take a deeper dive on the subject, the best explanation of it I've read (which -- perhaps sadly -- doesn't use the term "closure" at all) is in chapter 3.2 of Structure and Interpretation of Computer Programs.

The bad news is, that book was written about a language that's a bit off topic here (Scheme, the language closures were invented for.)

The good news is, if you want to read it, the whole book is online. Here's a link to the chapter I mentioned:

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-21.html#%_sec_3.2

Hope this helps!

Casey

On Aug 5, 2013, at 1:44 AM, psea denis.lukichev@gmail.com wrote:

Hi Smalltalkers!

Here is a question I can't find answer with google. In short: Does block parameters and block local variables are the same thing (semantically) inside closure? It looks like it's not. Below the explanation.

=================== Here is the accumulator function (first attempt):

makeAcc := [ :acc | [:n | acc:=acc+n. acc]]

It turns out it doesn't work as intended:

a1 := makeAcc value: 10 a1 value: 1 => 11 a1 value: 1 => 11 a1 value: 2 => 12

==================== Here is the second attempt:

makeAcc := [ :acc | | total | total:=acc. [:n | total:=total+n. total]]

And it does work as intended:

a1 := makeAcc value: 10 a1 value: 1 => 11 a1 value: 1 => 12 a1 value: 2 => 14

So if we use the local variable to store accumulator it works as it should and remembers the value between function (block) calls. But if we use block parameter to store the value of accumulator it does not remembers the value between calls. Why is it so?

P.S. Sorry for my English. I do all my best.

-- View this message in context: http://forum.world.st/Modify-block-closure-parameters-tp4702118.html Sent from the Squeak - Beginners mailing list archive at Nabble.com. _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners

I didn't read your post clearly enough. Yep, that would seem odd. You may have a bug there. I'm not sure why that happens. It looks like the outer context isn't taking the assignment, but hanging onto the initial value it receives from #value:.

I'm not totally sure we should expect to be able to do what you're trying to do in modern Squeak. I haven't assigned to a block arg in a long time (I keep allow block assignments off unless I'm loading old code.) I don't know what the status is there. I run a relatively recent Cog VM on a 10.7.5 Mac and I'm seeing the same behavior in Squeak 4.4.

When I switch to an old VM (3.8.18Beta3U) and run Squeak 3.0, your snippet works as expected. I'm not sure if this is in the image or the VM yet, or whether it's expected behavior or not with allowBlockArgumentAssignment (Again, I usually turn it off.)

The main take away here is, don't do that:) as it's a back-compat feature and it really ought to have a big sign on it that says DEPRECATED. If you're trying to load some older code and running into this, it might be better to actually rewrite it not to assign to block arguments in my opinion (and maybe I'm nuts.)

Can you tell me what VM you're using?

Smalltalk vmVersion "this will tell us"

And also which version of Squeak?

SmalltalkImage current systemInformationString "ditto"

Also, what's the OS of the host system?

On Mon, Aug 5, 2013 at 1:44 AM, psea denis.lukichev@gmail.com wrote:

Hi Smalltalkers!

Here is a question I can't find answer with google. In short: Does block parameters and block local variables are the same thing (semantically) inside closure? It looks like it's not. Below the explanation.

=================== Here is the accumulator function (first attempt):

makeAcc := [ :acc | [:n | acc:=acc+n. acc]]

It turns out it doesn't work as intended:

a1 := makeAcc value: 10 a1 value: 1 => 11 a1 value: 1 => 11 a1 value: 2 => 12

==================== Here is the second attempt:

makeAcc := [ :acc | | total | total:=acc. [:n | total:=total+n. total]]

And it does work as intended:

a1 := makeAcc value: 10 a1 value: 1 => 11 a1 value: 1 => 12 a1 value: 2 => 14

So if we use the local variable to store accumulator it works as it should and remembers the value between function (block) calls. But if we use block parameter to store the value of accumulator it does not remembers the value between calls. Why is it so?

P.S. Sorry for my English. I do all my best.

-- View this message in context: http://forum.world.st/Modify-block-closure-parameters-tp4702118.html Sent from the Squeak - Beginners mailing list archive at Nabble.com. _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners

These should be informative:

http://www.mirandabanda.org/cogblog/2008/06/07/closures-part-i/ http://www.mirandabanda.org/cogblog/2008/07/22/closures-part-ii-the-bytecode... http://www.mirandabanda.org/cogblog/2008/07/24/closures-part-iii-the-compile...

On Tue, Aug 6, 2013 at 2:14 PM, Louis LaBrunda Lou@keystone-software.comwrote:

Hi Guys,

FWIW, VA Smalltalk doesn't allow changing block arguments.

Lou

On Tue, 6 Aug 2013 13:42:33 -0700, Casey Ransberger casey.obrien.r@gmail.com wrote:

...

I didn't read your post clearly enough. Yep, that would seem odd. You may have a bug there. I'm not sure why that happens. It looks like the outer context isn't taking the assignment, but hanging onto the initial value it receives from #value:.

I'm not totally sure we should expect to be able to do what you're trying to do in modern Squeak. I haven't assigned to a block arg in a long time

(I

...

keep allow block assignments off unless I'm loading old code.) I don't

know

...

what the status is there. I run a relatively recent Cog VM on a 10.7.5 Mac and I'm seeing the same behavior in Squeak 4.4.

When I switch to an old VM (3.8.18Beta3U) and run Squeak 3.0, your snippet works as expected. I'm not sure if this is in the image or the VM yet, or whether it's expected behavior or not with allowBlockArgumentAssignment (Again, I usually turn it off.)

The main take away here is, don't do that:) as it's a back-compat feature and it really ought to have a big sign on it that says DEPRECATED. If you're trying to load some older code and running into this, it might be better to actually rewrite it not to assign to block arguments in my opinion (and maybe I'm nuts.)

Can you tell me what VM you're using?

Smalltalk vmVersion "this will tell us"

And also which version of Squeak?

SmalltalkImage current systemInformationString "ditto"

Also, what's the OS of the host system?

On Mon, Aug 5, 2013 at 1:44 AM, psea denis.lukichev@gmail.com wrote:

...

Hi Smalltalkers!

Here is a question I can't find answer with google. In short: Does block parameters and block local variables are the same thing (semantically) inside closure? It looks like it's not. Below the explanation.

=================== Here is the accumulator function (first attempt):

makeAcc := [ :acc | [:n | acc:=acc+n. acc]]

It turns out it doesn't work as intended:

a1 := makeAcc value: 10 a1 value: 1 => 11 a1 value: 1 => 11 a1 value: 2 => 12

==================== Here is the second attempt:

makeAcc := [ :acc | | total | total:=acc. [:n | total:=total+n. total]]

And it does work as intended:

a1 := makeAcc value: 10 a1 value: 1 => 11 a1 value: 1 => 12 a1 value: 2 => 14

So if we use the local variable to store accumulator it works as it

should

...

...

and remembers the value between function (block) calls. But if we use

block

...

...

parameter to store the value of accumulator it does not remembers the

value

...

...

between calls. Why is it so?

P.S. Sorry for my English. I do all my best.

-- View this message in context: http://forum.world.st/Modify-block-closure-parameters-tp4702118.html Sent from the Squeak - Beginners mailing list archive at Nabble.com. _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners

---

Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon mailto:Lou@Keystone-Software.com http://www.Keystone-Software.com

---

Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Wed, 7 Aug 2013, psea wrote:

Ok, i've got it. So in ST it's just not allowed assign to a block argument for some reason. Let's consider it a language feature. And it's ok,

It's a compiler bug. The compiler doesn't handle this case. - TempVariableNode >> #analyseClosure: returns if the receiver is a block argument without checking the preference. - BlockNode >> #postNumberingProcessTempsWithin:rootNode: only checks the temporaries, but not the arguments of the receiver. - Even if the above two are fixed, the temp index is still out of bounds, because removing arguments is not supported (see #removeTempNode:ifAbsent: and its sender), so the original temp for the argument will be kept.

different language - different rules. Thanks for pointing me on that! Now, I've turn off allowBlockArgumentAssignment property.

What's worried me is that in other languages I'm familiar with it's a normal thing to assign to a function argument (Scheme, C, Python, JavaScript).

Storing into a block or method argument is considered bad practice. Support for it is/was planned to be removed. Even though it can yield somewhat better performance, it's something you'll rarely see in Smalltalk code.

answer to your questions: Smalltalk vmVersion 'Squeak3.10.2 of 11 February 2010 [latest update: #9314]' SmalltalkImage current systemInformationString "ditto" 'Squeak4.3 latest update: #11860 Current Change Set: Unnamed1' Windows XP.

PS But you should agree with me that

makeAcc := [ :acc | [:n | acc:=acc+n. acc]]

looks a little bit better and concise than

makeAcc := [ :acc | | total | total:=acc. [:n | total:=total+n. total]]

There's no need to explicitly return 'total' from the inner block, because the assignment yields the same value:

makeAcc := [ :acc | | total | total := acc. [ :n | total := total + n ] ]

Levente

:-)

And thanks for the links.

-- View this message in context: http://forum.world.st/Modify-block-closure-parameters-tp4702118p4702410.html Sent from the Squeak - Beginners mailing list archive at Nabble.com. _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners

At Wed, 07 Aug 2013 15:05:56 -0700, Edwin Castro wrote:

On 8/7/13 12:33 PM, Levente Uzonyi wrote:

...

On Wed, 7 Aug 2013, psea wrote:

...

What's worried me is that in other languages I'm familiar with it's a normal thing to assign to a function argument (Scheme, C, Python, JavaScript).

Storing into a block or method argument is considered bad practice. Support for it is/was planned to be removed. Even though it can yield somewhat better performance, it's something you'll rarely see in Smalltalk code.

Why is storing into a block or method argument considered bad practice? Better performance seems like a good reason to follow the practice. I must assume there are dangers, non-obvious to beginners like me, which causes the practice to become bad. Of course, one reason is that Squeak doesn't properly support it today but as mentioned earlier other ST systems support the practice so I'm curious what causes it to be considered bad.

One reason is that it would prevent the edit and restart debug session from being effective. If some arguments are rewritten by the time you decided to restart the context, you don't get a repeatable result.

The above being one reason, the overall design that any program should aspire to was to make functions/methods/blocks pure froms side-effects whenever possible, and actions/side-effecting part isolated. Dan and Alan both have written and talked about that idea.

-- Yoshiki

GNU Smalltalk also doesn't allow changing block arguments.

-- View this message in context: http://forum.world.st/Modify-block-closure-parameters-tp4702118p4702906.html Sent from the Squeak - Beginners mailing list archive at Nabble.com.