On 3 June 2015 at 02:16, Peter Uhn��k <i.uhnak@gmail.com> wrote:

But I would like them to be defined like this:��

[ inc: x | x + 1 ].��
(inc: 3) = 4

[add: x to: y | x + y ].
(add: 3 to: 4) = 7.

What do you think? Is it feasible?��

But you still need to have the block saved in a variable. You cannot pollute global namespace with names of parameters within the block,

The block would still be saved in a variable -- I see that happening behind the scenes.��

In other words, you would have something like this:

[ inc: x | x + 1 ].��

(inc: 3) = 4.��

inc class = BlockClosure

��

[add: x to: y | x + y ].

(add: 3 to: 4) = 7.

addto class = BlockClosure��

not to mention the fact that most blocks in the system have same parameter names.
Now while the idea seems interesting; I cannot imagine how it would work in practice. Imagine collection's "do:" method explicitly stating the name of the argument, which would force me to name it in such and such way which would actually impair the readability.

��

I don't see that problem, as anonymous blocks would remain the same as now. You will still have this: ��

(1 to: 5) do: [ :x | x + 1 ]

��

My extensions are syntactic sugar to store and evaluate a block. They wouldn't help in a case like this:��

Point class >> incBlock
�� ^[: x | x + 1]

b := Point incBlock.��

I am sure others will have different opinions.

However if you want to try it out, you should apart from Opal have to look also at AST-Core since you are changing syntax.

Thanks for the pointers.��

��

��

Also I am thinking that combination of variable name + named arguments could perhaps be done purely with overriding doesNotUnderstand: method in BlockClosure and calling value:value: internally. (Or even cull:cull:, but form what I've heard that has some dire performance issues); this could perhaps even solve my comment about enforced naming.

Peter