Brian Wisti
14-Dec-2006 1:33:16 |
I think 'apply'/'reapply' is in keeping with what I've learned of REBOL so far. Let people decide on their own if they want the block reduced rather than making an assumption. |
rebolek
14-Dec-2006 2:16:26 |
I agree. I can REDUCE myself and some times I prefer to COMPOSE and not to REDUCE. So APPLY/REAPPLY is good idea. |
Gregg Irwin
14-Dec-2006 2:21:54 |
Agreed. Flexibility it important, as is consistency. REDUCE/ONLY is also useful, like COMPOSE. |
Ladislav
14-Dec-2006 4:12:44 |
agreed, APPLY should not reduce the block. It is more flexible and useful. |
Anton Rolls
14-Dec-2006 5:08:52 |
I am not sure, but, because I am not sure, I would go for the safest option, which is not to reduce. |
Oldes
14-Dec-2006 5:58:36 |
Me too... not to reduce by default... but I'm not sure if I like the REAPPLY - if I would be a newcomer, I would probably think about it like about "repeated apply" or something like that, which can confuse someone. |
Rebolek
14-Dec-2006 6:17:22 |
Oldes: You're right it may confuse newcomer - but that's same with "MOLD/REMOLD, FORM/REFORM, JOIN/REJOIN" and so on. I remeber I had problems too, but then I understood. Maybe some note should be added to documentation that words starting with RE- first reduces what follows. Not such a big problem, anyway. |
Goldevil
14-Dec-2006 8:54:40 |
I agree with every body here. No automatic reduce.
It's funny because another person ask my if the "re" prefix is something related to regular expressions.
As Rebolek explain, it's consistent with reform or rejoin to use REAPPLY. The newcomer will quickly understand the logic of the RE prefix. Maybe the documentation can contain a list of "automatic reduce functions".
|
Maxim Olivier-Adlhoch
14-Dec-2006 10:25:56 |
going with the familly ;-)
don't reduce. |
Brian Hawley
14-Dec-2006 10:32:01 |
I vote to not reduce. Let the programmer decide.
Does apply handle refinements, and if so, how and with what syntax? |
Edoc
14-Dec-2006 15:43:32 |
... "MOLD/REMOLD, FORM/REFORM, JOIN/REJOIN" ...
and repend
Not to mention potential confusion this convention introduces for: remove replace resend rename recycle |
Jaime Vargas
14-Dec-2006 21:12:33 |
Yeah. Don't reduce. I hope that math funcs are adjusted to handle unary args. So that this experessions works as expected.
apply :+ [1 2 3 4] ;== 10
apply :+ [1] ;== 1 |
tom
14-Dec-2006 21:39:01 |
ditto |
Robert
15-Dec-2006 4:42:52 |
APPLY / REAPPLY is good. |
Norm
16-Dec-2006 14:11:20 |
At times I act as lexicograph, so excuse me for being the devil's advocate.
I do not know the Lisp concept, but in the Synonym Finder 1978 edition:
'Apply' : use, utilize, engage, employ, put to use, bring to bear, practice, exercise, bring into play, execute, bring into effect.
Technically what you do here is create a denomination for your fonction. Nothing to be banned there. But, as that denomination is contrary to the usual meaning of the word, you engulf yourself against the grain of a generally admitted presupposition about words : when you use a name, you are supposed to use in within its usual meaning. If not, each time you explain the function, you serve your reader that the word is not used, in the usual sense, but it is an arbitrary denomination of the function, that specifically does not import its usual meaning. My experience of it, most will be too busy to dare hear your explanation. Practically, it does force you to explain repeatedly that apply does not apply. The Liar paradox may be a good philosophical challenge to presuppositions about cartesian dogmatic knowledge, but a formal language should resist to beg those difficulties inappropriately.
As there are no explanations on the function, should we suppose it is a name for map ? How such 'apply' function would be different of others, those that are there, those that are coming shortly. Then comments on the appropriateness of the naming convention would be more relevant. This comment is an invitation to discuss the matter on its merits, if need be. |
Brian Hawley
16-Dec-2006 18:45:36 |
Norm, the dictionary meaning of APPLY is quite on target for the actual behavior of this function. On the other hand you make an excellent argument against any REAPPLY function, since the meaning of that word would be at odds with the behavior of that function.
As for how APPLY is different from other similar functions, such as DO, it would be similar to the difference between using a hammer to push in a nail (APPLYing the hammer to the nail) and pushing in the nail with your bare hands (DO the nail). |
Karol Gozlinski
18-Dec-2006 7:26:52 |
Will apply function have optinal block for providing refiments? |
Ladislav
20-Dec-2006 4:02:24 |
apply :+ [1 2 3 4] ;== 10
apply :+ [1] ;== 1
really may be useful and I vote for it too, if it isn't prohibitively expensive. |
Ladislav
20-Dec-2006 4:13:59 |
OTOH, the above behaviour may contradict other design goals:
- optional argument handling (refinements)
- how should apply :+ [] behave? |
Anton Rolls
20-Dec-2006 9:31:17 |
When a native reduces a block, that may not be quite the same as when we reduce a block using REDUCE, is it?
When we REDUCE a block we produce a new block with the reduced contents. I expect a native has the option of either doing the same, or evaluating each item in the block as each item is visited, thus avoiding the creation of a new block. |
Henrik
20-Dec-2006 11:51:01 |
apply :+ [1 2 3 4] ;== 10
I've been looking for this kind of functionality for a while, but I would want it for computational speed, not plain convenience, otherwise such functionality could be built with mezzanines in R2. Maybe it should be done with natives for SUM, PRODUCT, etc.
apply :+ [1] ;== 1
The above might seem clever to squeeze in when summing up numbers, but it would produce unexpected results rather than an error about not enough arguments, when doing something else. That isn't easily predictable.
It should be:
apply :+ [1] ;== error!
And:
apply :+ [] ;== error!
Like above, I think this should produce an error. This is expected when using the function normally and it would be predictable to do that here as well. |
Henrik
20-Dec-2006 11:59:37 |
By the way, to protect against these errors, it would be simple to test:
numbers: [14 2 3 7 5]
if zero? mod length? args length? first :+ [
apply :+ numbers
] ; == none
|
Henrik
20-Dec-2006 12:01:50 |
Sorry, I missed a point about the above example. Please ignore it. |
felix
4-Mar-2007 8:40:13 |
since this came out, i would like to point your attention to what APL/A+/K/Q(kdb+) does with what it calls 'adverbs'. these are function derivators which take a function as an argument and return another function with a modified behaviour when applied to its arguments.
ex:
- over (/): +/1 2 3 -> 6
- scan (\): +\1 2 3 -> 1 3 6
- each/each pair('):1 2 3,'4 5 6 -> (1 4;2 5;3 6)
- each previous(':): -':2 3 5 1 4 -> 2 1 2 -4 3 (deltas)
- each right (/:) / each left (\:): "c:/",/:("windows";"program files") -> ("c:/windows";"c:/program files")
i'm not a rebol programer (but i like the rebol ideas), so these might be there already. if not, i think this will be a natural fit for rebol list/block comprehension.
there are also some corner cases like parallel application over multiple threads, stop conditions for self extending lists in "over" application to avoid infinite loops, etc... |
You can post a comment here. Keep it on-topic.
