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