6
$\begingroup$

Reading both OperatorApplied & CurryApplied function documentations seems to indicate that they are essentially the same function.

If they are not the same, can someone point out the difference? When would I use one of these over the other? Why have both functions?

$\endgroup$
5
  • 1
    $\begingroup$ Your policy question is hard to answer for us since we are not WRI. The two functions look very similar indeed, but they are both experimental. I wonder if perhaps WRI is "trying them out" to see which version catches on. It may also be a way of providing "syntactic sugar" for users. Consider for instance the introduction of MapApply[f, expr] to accomplish the existing f @@@ expr in version 13.1, and many other such examples before. $\endgroup$
    – MarcoB
    Oct 4, 2022 at 11:43
  • 1
    $\begingroup$ Looks like the 1-arg form of these functions is different. $\endgroup$
    – Greg Hurst
    Oct 4, 2022 at 13:26
  • 3
    $\begingroup$ I don't understand this question - take the very first documentation example for OperatorApplied and substitute CurryApplied and it will not work. Therefore they are different. $\endgroup$
    – Jason B.
    Oct 4, 2022 at 13:42
  • 4
    $\begingroup$ @JasonB. Sure, you are technically right. However, I think this question still raises an important point, if implicitly: the documentation does a poor job of pointing out the differences or intended use cases for these two objectively very similar functions, instead limiting itself to formulaic examples. I had to open the two documentation pages side by side in my browser to spot the differences. $\endgroup$
    – MarcoB
    Oct 4, 2022 at 15:22
  • $\begingroup$ Technically correct is the best kind of correct :-) I try to zoom in on the answerable part of a question. I can't speak to the design of these functions, I don't know when I would want to use either of them so I do not. $\endgroup$
    – Jason B.
    Oct 4, 2022 at 16:33

1 Answer 1

5
$\begingroup$

Trying my hand at mind-reading, I think that the difference is semantic, maybe with a sprinkling of expressive opportunity. But let me approach this from the duplicated function question,

what is WRI policy for duplicated functions

I won't try to speak about any formal policy, but a certain amount of duplication can be useful. Consider ConstantArray. One could argue that ConstantArray is superfluous, because we can accomplish the same thing with Table:

ConstantArray[x, {5, 3}]
(* is equivalent to *)
Table[x, {5}, {3}]

But the subtle differences might come in handy. If you already have the dimensions in the form {5, 3} then you can apply ConstantArray directly without destructuring your dimension data. But there is also an expressiveness characteristic here. Scanning your code and seeing ConstantArray provides an extra semantic hint that Table does not.

And so we imagine the time when someone at WRI suggested implementing some sort of currying functionality. Typically, currying is just about making a new function with a reduced argument list while keeping the ordering of those arguments. So, f[x, y, z] could be curried to f[x, y] (applied as f[x, y][z]). This suggests a form like CurryApplied[n][f]. But, Mathematica almost always prefers very generalized functions, and so one imagines that permuting the arguments was discussed, the result being a form like CurryApplied[{i1, ... , in}][f].

But now we've opened the semantic can of worms. Should we re-define currying to be a more general operation, or should we envision the "standard" currying as a specific case of a more general operation (which maybe we'll call OperatorApplied)? CurryApplied is semantically anchored to reducing the argument list, but it can be generalized to permuting the argument list. OperatorApplied is semantically anchored to permuting the argument list, but it can be used for the special case of reducing the argument list.

And so the big question: which one should we add to the language? It seems the answer was "both", but since they're each tagged as experimental, we don't yet know WRI's final answer.

The semantic distinction is most clear in how the short forms were defined. For an integer n, CurryApplied[n] has a natural interpretation in the reduce-argument-list semantic, whereas OperatorApplied[n] does not. For a function f, OperatorApplied[f] has a natural interpretation in the permute-the-arguments semantic, whereas CurryApplied[f] does not. So, for all of the overlap in functionality for longer argument lists, one can imagine that it would be nice to have both functions, since the most common cases probably involve short argument lists.

$\endgroup$
2
  • $\begingroup$ I edited the original question to narrow the focus (rollback if appropriate), I believe your answer is still congruous but you may wish to modify accordingly. $\endgroup$
    – Jason B.
    Oct 6, 2022 at 1:20
  • $\begingroup$ Whats the reason they started these experimental features in the first place, if Curry was already a feature? $\endgroup$
    – ions me
    Dec 21, 2022 at 12:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.