Haskell has something called “currying” and it lets them write stuff like:
map (add 2) [1, 2, 3]
That results in [3, 4, 5]. So it meant the same thing as what Rebol would say as
map-each x [1 2 3] [add 2 x]. Effectively, it’s as if it noticed ADD didn’t have enough parameters…but instead of erroring it assumed you wanted to create a function that would just be taking the 3 later. (Technically speaking all functions in Haskell take only take one parameter, and that’s related to the “currying”, so it’s not like it had to do something special to “notice”.)
If we imagine MAP as a function in Ren-C that did the same thing (take a function and apply it for each member of a series, return a series of the results) you’d have to do this as:
map (specialize 'add [value1: 2]) [1 2 3]
That’s wordy. It also forces you to remember the name of add’s parameters, when you may not care (and parameter names may tend to change).
So imagine we have a variant of specialization that doesn’t make you name arguments, it just kind of grabs as many as you supply…in this case one. Let’s call this PARTIAL for a moment:
map (partial 'add ) [1 2 3]
That’s brief, but still kind of wordy. Might it be nice if there were a way to do this that was briefer, like…say…
map :(add 2) [1 2 3]
In such a world, plain (add 2) would still be an error, since there was no colon.
One place this would be handy is because I’ve been trying to think about how to modify things like SHOVE and MATCH to operate on things other than the first argument. Right now you can say:
>> obj: make object! [dv: enfix :divide] >> 8 -> obj/dv 2 == 4
That lets you shove 8 as the left hand parameter of an enfix parameter dispatched via path. But what if you wanted it the other way around, to make it the second parameter, so you were dividing by 8. It might be nice to be able to say:
>> 8 -> :(obj/dv 2) == 0.25
So that would “shove” the parameter to be after the 2. As another example, today’s MATCH works on the first argument:
>> match parse "aab" [some "a"] // null >> match parse "aaa" [some "a"] == "aaa"
But what if instead of getting the data when the expression succeeded, you wanted the rule?
>> match :(parse "aab") [some "a"] // null >> match :(parse "aaa") [some "a"] == [some "a"]
So MATCH is still grabbing the “first argument” of the function you give it on a match. You just made a partial function whose first parameter was the rule, since the data was specialized into the partial.
I had considered making this the natural syntax of match (…) … but that just feels like it is getting in the way of when you want to use GROUP! just for grouping. This feels like a different operation, and one that’s useful enough to build in.