ap() and currying

I’ve tried to follow the doc examples of ap() and lodash’s curry(), but run into type problems:

import { curry } from 'lodash';
import { Result } from 'true-myth';

const add = (a: number, b: number): number => a + b;
const curriedAdd = curry(add);

console.log(
  Result.of(curriedAdd)
    .ap(Result.of(1)).ap(Result.of(5))
    .unsafelyUnwrap()
);

const merge3Strs = (a: string, b: string, c: string): string => `${a} ${b} ${c}`;
const curriedMerge = curry(merge3Strs);

console.log(
  Result.of<typeof curriedMerge, string>(curriedMerge)
    .ap(Result.of('a')).ap(Result.of('b')).ap(Result.of('c'))
    .unsafelyUnwrap()
);

The first usage has:

The 'this' context of type 'Result<CurriedFunction2<number, number, number>, unknown>' is not assignable to method's 'this' of type 'Result<(a: number) => number, unknown>'.

and the second:

The 'this' context of type 'Result<CurriedFunction3<string, string, string, string>, string>' is not assignable to method's 'this' of type 'Result<(a: string) => string, string>'.

but the code works correctly in both places.

Has lodash’s typing changed so that it’s now incompatible, or is there something wrong here?

[CrossEye]

Sorry if I sounded offended. If “bonkers” was the worst thing Ramda got called today, it would be a very good day, indeed! 😉 I was just curious about the reason.

Ramda suffers from envy of better FP languages. “If we only had Haskell’s sections,” “If we could simply use placeholders like in Erlang,” etc. When we can do something that helps scratch that itch, we tend to do so. Transducers were probably a mistake, but the hot new thing coming out of Closure, and seemed like a good fit for our adolescent library. The placeholders is in that in-between state, maybe not a real mistake, but never a really clear fit either. I keep thinking we’ll do something like lodash’s rearg and let that combine with simpler currying to handle such cases.

In any case, although I haven’t actually used true-myth yet, I’ve enjoyed watching it develop. Thanks for all your effort.

[chriskrycho]

Hey @thewilkybarkid, thanks for the report and sorry for the delay in responding—thought I had notifications set up correctly for this repo but apparently not! I’ll take a look sometime soon. I would guess lodash’s types changed, because there are features in TS from the last year or so (much more recent than when the docs were written) which allowed lodash to be much more robust—but also changed inference.

I’ve been meaning to take a pass on freshening up this library soon anyway, so this and a couple other issues should get resolved then!