new function: recall

[shiftinterrupt]

This is in reference to #2980. It supports a particular class of function: A unary function that if returns a function, is also unary with this same rule.

[CrossEye]

Can you explain the choice of the name "recall?" To me that mostly has to do with remembering things.

[shiftinterrupt]

I'm terrible at naming. The idea is that it calls, then re-calls, etc. collapse also works.

[CrossEye]

I'm extremely loathe to add new variadic functions to Ramda.

I would much rather deal with an API such as this:

recall (f) (a, b) //=> f (a) (b)

(Even that probably isn't possible. I'm quite certain that we will need to supply the final arity. But that's a different comment.)

I know that the generated function is going to be polyadic. That's the whole point. And it's not even as though it always returns functions of a specific arity. But I'm hoping to make pipe, compose and other leftover variadic functions into fixed-arity ones and not add new ones.

[shiftinterrupt]

I feel the same way, I was just mirroring call. The list of values can be passed as an array instead, as in apply.

[CrossEye]

Yeah, the call API was an early mistake as we felt our way around this space.

But I wouldn't want the arguments to be wrapped in an array. I was just thinking that this function would have to be a two-pass call: recall takes a curried function and returns a function. You call that with the n arguments you would have supplied one at a time to the original:

const foo = (a) => (b) => (c) => a + b + c

const bar = recall (foo)

bar (1, 2, 3) => 6

(Or some equivalent of this that accepts an arity instead of depending on the function's arity.)

[shiftinterrupt]

The idea is to call a function with a set of values in the fashion of call and apply. The difference here is there is no notion of arity since the n-order function is composed of unary functions. The list of values supplied doesn't represent an arity of a function, rather a serial list of singular inputs fed to the n-order function. So returning a function defeats the purpose in which case I'd rather just use uncurryN somehow.

[CrossEye]

Perhaps then we're at cross purposes. I was thinking that the goal was a to bring behavior similar to uncurryN to work with Ramda-styles curried functions. I thought we were mostly just removing the word "manually" from the docs.

I'm not sure what your goal is hers.

[shiftinterrupt]

Ideally uncurryN would be made to work but I'd still want this functionality, otherwise I'd have just submitted a patch. Is anyone looking into it?

[CrossEye]

I don't think so. I've been pulled into something else, and haven't had any real free time for Ramda in the past week. If no one does it before then, I will try to get to it this weekend. (You can do it yourself. Any conversations of importance about this would be in the issues here; so a GitHub search should probably show anything of importance that isn't already captured in the source or the tests.)

[CrossEye]

I'm quite sure that we need to supply the arity here as we do with uncurryN.

What happens if our target output is a function? What if we want to convert

const makeHandler = (a) => (b) => (evt) => ({do: 'something', with: 'a, b, and evt'})

so that it can be used as

something .addHandler (recall (makeHandler, 42, false) )

where addHandler accepts a function?

[shiftinterrupt]

This is a good use. The value returned can be whatever it needs to be, including just another function. If we supply a function a => b => c => d => a + b * c + d and want a function a particular depth, we just provide values up to that depth. For example, [ 2, 3 ] if we want the function c => d => 5 * c + d.

[CrossEye]

I think I misread before and didn't notice && i < numArgs. My initial reading suggested that this use case wouldn't be possible with that implementation.

[CrossEye]

I don't feel that this tests proves what it claims to prove. Perhaps with an innermost function in fn that has an optional parameter and acts differently based on its presence.

var fn = function(a) {
  var x = a + 1;
  return function(b) {
    var y = x * b;
    return function(c, d = 0) {
      return y * c + d;
    };
  };
};

where

fn (1) (2) (3)          //=> 12
fn (1) (2) (3, 4)       //=> 16
recall (fn, 1, 2, 3, 4) //=> 12

But then that makes me wonder if this is the correct behavior. It seems to me that if we do this as :: Int -> (a -> b -> ... -> n -> x) -> ((a, b, ..., n) -> x), then we could write this so that

recall (3, fn) (1, 2, 3, 4) //~> fn (1) (2) (3, 4)

which feels more in keeping with other Ramda functions.

[shiftinterrupt]

It's intended to support a special class of high-order function, those composed of unary functions. E.g. const f = g => h => v, where f, g, and h are unary functions. In compose, all functions must be unary except the last because the inputs to the last function are outside the workings of compose. Similarily, the last value of the high-order unary function can be anything, including a polyadic function, because it's considered to be the value and outside the workings of recall. The tests themselves could use some work though, I agree.

[CrossEye]

Yes, I was responding to the test case. I don't think it really demonstrated that it "accepts no more than N arguments for an N-order function". But I am curious about which behavior we actually want. I'm thinking that it might be a little different from what's in this implementation.

[CrossEye]

Thank your for the PR. I'm afraid I forgot to do the research into why uncurryN doesn't already handle this. I will try to do so soon.

Did you look into updating uncurryN to also handle this case? Because if there's not some compelling reason not to do so, it seems that would be a much better solution.

[shiftinterrupt]

@CrossEye No problem. I gave a cursory look into uncurryN. It seemed fine. I didn't notice anything glaring and figured I'd need to dig further and see how currying was being handled. I'll need to make some time for that.