On Wed, 2015-06-03 at 03:16 +0200, Peter Uhnák 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?
Francisco, Interesting. Looks handy, too :-) But I found the syntax bit confusing as it looks like that the block is created and never stored. Maybe add:to:= [:x :y | x + y ] add: 3 to: 4 I'm not terribly happy with that either, but...
But you still need to have the block saved in a variable. You cannot pollute global namespace with names of parameters within the block, 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 am sure others will have different opinions.
This is handy when one needs to define a method-local function sort of things. I do that often using the variable + value:value: syntax but it's ugly and not intention revealing (unless you're really used to this idiom)
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.
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.
Using a doesNotUnderstand: here would have performance problems. (unless Cog does something super-smart) Jan
Peter