Function composition challenge for type system

How would you type the following JavaScript function?

function wrap(fn) { return (a, b) => fn(a, b); }

Obviously, the naive typed declaration would be:

type Func<A, B, R> = (a: A, b: B) => R;
declare function wrap<A, B, R>(fn: Func<A, B, R>): Func<A, B, R>;

But it does not really describe its contract. So, let’s say if I pass generic function, which is absolutely acceptable, it’s not gonna work:

const f1 = wrap(<T>(a: T, b: T): T => a || b);

It’s clear that f1 must be <T>(a: T, b: T) => T, but it’s inferred to be (a: {}, b: {}) => {}. And that’s not about type inferring, because we wouldn’t be able to express that contract at all. The challenge here is that I want to be able to capture/propagate not only the generic parameters themselves, but also their relations. To illustrate, if I add an overload to capture that kind of signatures:

declare function wrap<A, B, R>(fn: <T>(a: T, b: T) => T): <T>(a: T, b: T) => T;

then, I still wouldn’t be able to express

const f2 = wrap(<T>(a: T, b: T): [T, T] => [a, b]);

Because then I would need to add overloads of unbounded number of type compositions, such as [T], T | number, [[T & string, number], T] | Whatever … infinite number of variations.

Hypothetically, I could express with something like this:

declare function wrap<F extends Function>(fn: F): F;

but it doesn’t solve the problem either:

• F isn’t constrained to be requiring at least 2 arguments
  • F extends (a: {}, b: {}) => {} would work, but doesn’t currently, because it collapses F to (a: {}, b: {}) => {}
• it doesn’t allow to express modified signature components of F; see an example below

So then we come to more complicated things:

const wrap2 = fn => args => [fn(args[0], args[1])];
// so that
const f3 = wrap2((a: number, b: string): number|string => a || b); // (args: [number, string]) => [number|string]

How to express that in the type system?

A reader can think now that is very synthetic examples that unlikely be found in real world. Actually, it came to me when I tried to properly type Redux store enhancers. Redux’s store enhancers are powerful and built based on function compositions. Enhancers can be very generic or can be applicable to specific types of dispatchers, states etc etc. And more importantly they can be constructed being detached from specific store. If the issue falls to discussion I will provide more details of why it’s required there.

So where’s the proposal? I’ve been thinking of that for awhile and haven’t came out with something viable yet. However, this is something we can start with:

declare function wrap2<~G, Ʀ<T1, T2, R, ~G>>(fn: <...G>(a: T1, b: T2) => R): <...G>(args: [T1, T2]) => [R]);

Of course, ignoring the syntax, here’s what was introduced:

1. ~G is generic set of unbinded (no such word?) generic parameters with their constraints. Since it’s not the same as generic type parameter, I’ve marked it with ~. So than it’s applied as <...G> that means that set becomes set of generic parameters. For example ~G=<T, R extends T>, so then <...G>=<T, R extends T>.
2. Ʀ<T1, T2, R, ~G> (maybe syntax Ʀ<T1, T2, R, ...G> would make more sense, btw) is a relation between T1, T2, R, ~G. It is another kind of generic information. It could be a set of relations, such as T1=number, T2=string, R=T1|T2=number|string. Important here, is that relations can introduce new names that can be used as generic parameters, and also, they can reference existing type parameters from enclosing generic info.

Probably, examples could help to understand what I’m trying to say:

// JavaScript
const f(f1, f2) => a => b => f2(f1(a), b);
// TypeScript
declare function f<~G1, ~G2, Ʀ<~G1, ~G2, A, B, R1, R2>>(
  f1: <...G1>(a: A) => R1,
  f2: <...G2>(r1: R1, b: B) => R2): <...G1>(a: A) => <...G2>(b: B) => R2;

// using
const g = f(
  /* f1 = */ <T>(a: [T, T]): [T, T] => [a[1], a[0]],
  /* f2 = */ <T, B extends T>(r1: [T, T], b: B[]): B[] => [...r1, ...b]);
// Inferred generic data (all can be set explicitly, syntax is pending):
// ~G1 = <T>
// ~G2 = <T, B extends T>
// Ʀ<~G1, ~G2, A, B, R1, R2> ->
//   A is [G1.T, G1.T],
//   R1 is [G1.T, G1.T],
//   R1 is [G2.T, G2.T],
//   B is G2.B[],
//   R2 is G2.B[]
// So the return type, type of const g would be
// <...G1>(a: A) => <...G2>(b: B) => R2 ->
//   <T>(a: [T, T]) => <G2_T extends T, B extends G2_T>(b: B) => B[]

Simpler example from the beginning:

// JavaScript
function wrap(fn) { return (a, b) => fn(a, b); }
// TypeScript
declare function wrap<~G, R<~G, A, B, C>>(
  fn: <...G>(a: A, b: B) => C): <...G>(a: A, b: B) => C;

// using
const f1 = wrap(<T>(a: T, b: T): T => a || b);
// is the same as explicitly
const f1: <T>(a: T, b: T) => T =
  wrap<
    /* ~G = */ ~<T>,
    <~<T>, A, B, C> -> [
       A is T,
       B is T,
       C is T]
   >(<T>(a: T, b: T): T => a || b);

Ok, guys, what do you think of this?

[jesseschalken]

See https://github.com/Microsoft/TypeScript/issues/9949 which uses const flip = f => (a, b) => f(b, a); as an example (which is basically the same).

I would rather that TypeScript inferred the genericity of an expression without all the extra syntax, the same way that Haskell and some other functional programming languages do.

To take this example from the OP:

const wrap = f => (a, b) => f(a, b);
const pair = (a, b) => [a, b];

with types

const wrap: <A, B, C>(f: (a: A, b: B) => C): (a: A, b: B) => C;
const pair: <T>(a: T, b: T) => [T, T];

(ignore that pair should have two type parameters instead of one)

When TypeScript sees wrap(pair), it has to unify (a: A, b: B) => C (parameter to wrap) with <T>(a: T, b: T) => [T, T] (type of pair). At this point, TypeScript doesn’t have any information for the type parameter T, so it just fills it with {} and keeps going, yielding (a: {}, b: {}) => [{}, {}].

TypeScript could just carry the type parameters forward without any new syntax, so instead of filling T with {}, it adds T to a list of unbound type variables, creating type assignments A = T, B = T, C = [T, T], and then uses the list of unbound type variables (T) as new type parameters, yielding <T>(a: T, b: T) => [T, T].

[zpdDG4gta8XKpMCd]

@jesseschalken

TypeScript could just carry the type parameters forward

isn’t it just common sense?

one can’t just “resolve” unspecified type parameters by {} at whim and call it a day, can they?

dang, i am so angry