Other useful common functions

[rbuckton]

In https://github.com/esfx/esfx/blob/master/packages/fn/src/common.ts I've gathered a bunch of useful one-off functions for FP-style development. If we are considering adding .constant and .identity, perhaps some of those make sense as well. There are at least two that might be worth adding to the standard library:

• noop() — Always returns undefined.
  • This is essentially the same as Function.prototype, though it might be useful to have a separate copy.
• lazy(factory, ...args) — Creates a function with the following properties:
  • When invoked for the first time, calls factory with the supplied arguments and returns the result
  • Any subsequent invocation returns the result of the first invocation.

There's a bunch of other ones in there, but most are very niche:

• incrementer — (start = 0, step = 1) => () => start += step
• decrementer — (start = 0, step = 1) => () => start -= step
• property — key => object => object[key]
• propertyWriter — key => (object, value) => object[key] = value
• invoker — (key, ...args) => (object, ...rest) => object[key](...args, ...rest)
• caller — (...args) => (func, ...rest) => func(...args, ...rest)
• allocater — (...args) => (ctor, ...rest) => new ctor(...args, ...rest)
• factory — (ctor, ...args) => (...rest) => new ctor(...args, ...rest)
• uncurryThis — Function.prototype.bind.bind(Function.prototype.call)
• complement — f => (...args) => !f(...args)
• both — (a, b) => (...args) => a(...args) && b(...args)
• either — (a, b) => (...args) => a(...args) || b(...args)
• fallback — (a, b) => (...args) => a(...args) ?? b(...args)

[celmaun]

+1 for uncurryThis, I think that actually is used way more in the wild (in diff. variations) than any of the other proposed helpers.

[ljharb]

uncurryThis is https://npmjs.com/call-bind, and it’s solved by https://github.com/tc39/proposal-bind-operator and https://github.com/js-choi/proposal-bind-this

[samhh]

There's a lot of prior art for noop and it's something I've seen used in almost every JS project. For reference in fp-ts it's called constVoid.

[celmaun]

@ljharb do you have a problem with this entire proposal?

[celmaun]

There are like a half dozen bind proposals, they keep getting binned.

[ljharb]

Of course i don’t. I think this is too large a list to be reasonable to add, and i think each addition will need its own motivation, and i don’t think there’s much value in an explicit noop when Function.prototype and ()=>{} exist.

[rbuckton]

Like I said in the OP, most of those are niche and I wouldn't expect them to be accepted (at least, not on Function). And I mentioned that noop is essentially Function.prototype.

I mentioned noop because it's more obvious than Function.prototype. I doubt most JS devs would even consider using Function.prototype as a no-op callback. The problem with () => {} is that its yet another object allocation and there's no reference equality. With a clearly-labeled, built-in noop you can write branching code paths that optimize for cases where the callback is unused without resorting to cb?.(). The same is true for a built-in identity function:

function * tap(iterable, cb) {
  if (typeof cb !== "function") throw new TypeError("Function expected: cb");
  if (cb === Function.noop) {
    yield* iterable;
    return;
  }
  for (const x of iterable) {
    cb(x);
    yield x;
  }
}

function * map(iterable, cb) {
  if (typeof cb !== "function") throw new TypeError("Function expected: cb");
  if (cb === Function.identity) {
    yield* iterable;
    return;
  }
  let i = 0;
  for (const x of iterable) {
    yield cb(x, i++);
  }
}

iterable
  |> tap(^, debugMode ? value => console.log(value) : Function.noop)
  |> map(^, addIndex ? (value, index) => ({ ...value, index }) : Function.identity)

The one I have used most frequently, though, is lazy:

const getResult = Function.lazy(complexComputation);
getResult(); // performs computation, returns result
getResult(); // returns result

[rbuckton]

Also, uncurryThis isn't really necessary if Partial Application advances, since you could then just write f.call~(...), but its a bit more obvious.

[ljharb]

fwiw i do like the idea of an API solution for it, even if PFA or the bind operator advances, but i wouldn't call it "uncurry" since "currying" is a confusing concept.

[samhh]

I'd argue currying is not confusing, merely unfamiliar. I've not worked with anyone who was unable to adapt to it even if, owing to current mainstream idioms, it's not what they were used to.

[ljharb]

I'm quite familiar and I still find the concept confusing. Either way, "unfamiliar" is pretty much the same as "confusing" when it comes to language design.

[samhh]

"Confusing" implies it's inherently hard to reason about whereas something merely unfamiliar may become comfortable and easy given a little time. It's an important distinction given users will be to varying extents unfamiliar with any new language construct.

[js-choi]

I’ve used complement, lazy (basically a memoization function), and n-ary versions of either and both (some-fn and every-pred in Clojure).

(To be honest, I’ve never used a specific noop function before in all my FP life. At most I might have done constant(null) or something. But I see that lodash.noop gets 400,000 NPM downloads weekly, so that’s something—though it’s difficult for me to see from its dependencies why people actually use lodash.noop.)

So I can see the appeal of many of these (particularly the complement and memoization functions). But @ljharb is right: the Committee will demand specific use cases and evidence of high frequency for each of these functions.

So I think a prerequisite for each of these functions (at least if we want it to have any chance in the Committee) would be to show that it’s been implemented in userland as one or more very popular libraries, along with specific use cases.

I also want to avoid this initial proposal becoming overly big at once. If the Committee shows that one of the proposal’s functions risks killing the entire proposal, then I will drop it. That goes for identity and for constant. Any controversial or complicated helper function can be punted to a future proposal.

complement and any/either maybe could be added if there are popular libraries that demonstrates existing demand for their use cases.

A memoization function might be complicated enough to warrant its own proposal.

---

I am uncertain whether including a call-bind/uncurry-this function would affect the chances of the resurrected bind-this operator that I will also propose to the Committee at the upcoming plenary meeting. I suspect that it might, which makes me hesitant to include it in this proposal.

[celmaun]

@js-choi Regarding your footnote, I think it would be on the contrary regarding affecting the chances. From my observation, for a syntax level change (+ competing proposals), you're looking at a good couple years to Stage 3. If Function.uncurryThis [1] gets there first (which is likely), then you can simplify your bind proposal greatly by saying it's basically syntactic sugar for Function.uncurryThis and complain about how verbose Function.uncurryThis is hehe. Then your bind proposal gets acceptance easy-peasy?

1: Agree about "curry" being confusing, so +1 for a better name. It's an annoying trend right now, functional programming terms are getting force-fed to the JS community.

[zloirock]

uncurryThis is npmjs.com/call-bind

Awesome alternative to Function.prototype.bind.bind(Function.prototype.call).