suggestion: dynamic function type

[amir-arad]

Following gcanti/fp-ts#177,
It would be great if we had a variadic generic function type before microsoft/TypeScript#5453 is resolved.

My best shot was this:
(I've opened a separate PR #7 for NumberToString as it seems useful on its own)

export type NumberToString = ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '10'];
export type Func<I extends number, A, R=void> = {
    0: ()=>R
    1: (a0:A[0]) => R
    2: (a0:A[0], a1:A[1]) => R
    3: (a0:A[0], a1:A[1], a2:A[2]) => R
    4: (a0:A[0], a1:A[1], a2:A[2], a3:A[3]) => R
    5: (a0:A[0], a1:A[1], a2:A[2], a3:A[3], a4:A[4]) => R
    6: (a0:A[0], a1:A[1], a2:A[2], a3:A[3], a4:A[4], a5:A[5]) => R
    7: (a0:A[0], a1:A[1], a2:A[2], a3:A[3], a4:A[4], a5:A[5], a6:A[6]) => R
    8: (a0:A[0], a1:A[1], a2:A[2], a3:A[3], a4:A[4], a5:A[5], a6:A[6], a7:A[7]) => R
    9: (a0:A[0], a1:A[1], a2:A[2], a3:A[3], a4:A[4], a5:A[5], a6:A[6], a7:A[7], a8:A[8]) => R
    10: (a0:A[0], a1:A[1], a2:A[2], a3:A[3], a4:A[4], a5:A[5], a6:A[6], a7:A[7], a8:A[8], a9:A[9]) => R
}[NumberToString[I]];

usage example:

const stringToNumber: Func<1, [string], number> = Number.parseInt; //works
const numberToNumber: Func<1, [number], number> = Number.parseInt; // breaks

However the first generic param, I seems redundant though I couldn't shake it off. I'm beginning to use this type in my own project, and I would welcome any improvement ideas.

@SimonMeskens

[gcanti]

Maybe through hlists?

export type THListToFunction<L extends THList, C> = {
  true: () => C
  false: {
    true: (a: THListHead<L>) => C
    false: {
      true: (a: THListHead<L>, b: THListHead<THListTail<L>>) => C
      false: {
        true: (a: THListHead<L>, b: THListHead<THListTail<L>>, c: THListHead<THListTail<THListTail<L>>>) => C
        false: 'error' // TODO more cases
      }[IsZero<THListLength<THListTail<THListTail<THListTail<L>>>>>]
    }[IsZero<THListLength<THListTail<THListTail<L>>>>]
  }[IsZero<THListLength<THListTail<L>>>]
}[IsZero<THListLength<L>>]

export type THListToCurriedFunction<L extends THList, C> = {
  true: () => C
  false: {
    true: (a: THListHead<L>) => C
    false: {
      true: (a: THListHead<L>) => (b: THListHead<THListTail<L>>) => C
      false: {
        true: (a: THListHead<L>) => (b: THListHead<THListTail<L>>) => (c: THListHead<THListTail<THListTail<L>>>) => C
        false: 'error' // TODO more cases
      }[IsZero<THListLength<THListTail<THListTail<THListTail<L>>>>>]
    }[IsZero<THListLength<THListTail<THListTail<L>>>>]
  }[IsZero<THListLength<THListTail<L>>>]
}[IsZero<THListLength<L>>]

Usage

import { THListToFunction, TupleLength, THListReverse, THListToCurriedFunction, TupleToTHList } from 'typelevel-ts'

type L = THListReverse<TupleToTHList<[number, string, boolean]>>
// type F = (a: number, b: string, c: boolean) => void
type F = THListToFunction<L, void>
// type C = (a: number) => (b: string) => (c: boolean) => void
type C = THListToCurriedFunction<L, void>

[amir-arad]

in a nutshell: improvement, but still...

basically same problems as with objects and tuples, I can't get the naive usage example to work.
there's a problem with recursive types (in this case TupleToTHList), where the counter has a default value, it can't be used indirectly via another type.
in this example (hlists), I'd like something like this:

export type Func<A, R=void> = THListToFunction<THListReverse<TupleToTHList<A>>, R>

so that I can use it like this:

declare function parseInt(string: string, radix?: number): number;
const stringToNumber: Func<[string], number> = parseInt;
// $ExpectError Type 'number' is not assignable to type 'string'
const numberToNumber: Func<[number], number> = parseInt;

The closest I got was:

export type Func<L extends THList, R=void> = THListToFunction<THListReverse<L>, R>

and I can use it like this:

declare function parseInt(string: string, radix?: number): number;
const stringToNumber: Func<TupleToTHList<[string]>, number> = parseInt;
// $ExpectError Type 'number' is not assignable to type 'string'
const numberToNumber: Func<TupleToTHList<[number]>, number> = parseInt;

I guess replacing the length withTupleToTHList is an improvement. I did however copy TupleToTHList as Args so that I can minimize the API clutter:

declare function parseInt(string: string, radix?: number): number;
const stringToNumber: Func<Args<[string]>, number> = parseInt;
// $ExpectError Type 'number' is not assignable to type 'string'
const numberToNumber: Func<Args<[number]>, number> = parseInt;

[amir-arad]

YES

export type Func<T, R=void, I = 0, L = THNil> = {
    true: Func<T, R, Increment[I], THCons<T[I], L>>;
    false: THListToFunction<THListReverse<L>, R>;
}[ObjectHasKey<T, I>];

[gcanti]

@amir-arad nice!

[amir-arad]

yeah... this is nice.
but, it doesn't scale. I can't use it to define APIs, it can't be used inside other types.
:(

[amir-arad]

the problem is with the way ObjectHasKey responds to tuples when I = 0 is involved. it has to be called from the first type in the stack or it reverts to false. I'm back at asking the user to use Args<[string]> instead of [string]

[SimonMeskens]

I would get rid of the I=0 through something like this, but it doesn't seem to work:

export type Func<T, R=void, L = THNil> = {
    true: Func2<T, Increment[0], R, THCons<T[0], L>>;
    false: THListToFunction<THListReverse<L>, R>;
}[ObjectHasKey<T, 0>];

export type Func2<T, I, R=void, L = THNil> = {
    true: Func2<T, Increment[I], R, THCons<T[I], L>>;
    false: THListToFunction<THListReverse<L>, R>;
}[ObjectHasKey<T, I>];

[SimonMeskens]

Does TupleLength work for you guys? It doesn't seem to work for me.

[SimonMeskens]

I think we're running into a compiler bug, where ObjectHasKey doesn't work on generic type parameters when used in an indexer or something like that.

[SimonMeskens]

@gcnew Do you happen to know why this code fails?

type A<T> = {
  true: 'true'
  false: 'false'
}[ObjectHasKey<T, '0'>]

type B = ObjectHasKey<[string], '0'> // B = "true"
type C = A<[string]> // C = "false"

Do you think your PR fixes this one?

[gcnew]

Unfortunately no, I don't know what's going wrong and my PR doesn't fix it either. I'll try to take a second look later tonight.

[gcnew]

In type A<T> = ..., ObjectHasKey<T, '0'> gets simplified to just "false" (you can observe that behaviour by changing the catch-all index signature to e.g. { [key: string]: 'lie' }). The rule that gets applied here is:

• Given a type parameter T with a constraint that includes a string index signature of type X, the apparent type of an indexed access type T[K] is X.

I'm not sure why this substitution is only selectively applied, though.

[gcnew]

To be honest StringContains is a bit hacky. When the key exists, the actual type should be 'true' & 'false' and when it doesn't - just 'false'. I guess it appears to work most of the time and returns naked "true" due to optimisations based on

• The operation { [P in K]: T}[X] is equivalent to an instantiation of T where X is substituted for every occurrence of P. For example, { [P in K]: Box<T[P]> }[X] is equivalent to Box<T[X]>.

[SimonMeskens]

A very large part of the useful abstractions in TypeScript end up being hacky mapped types. Perhaps we should just petition the TypeScript team to formalize a few fundamental ones into proper features of the language.

As for the topic of the issue, I feel like the feature is actually not that hard to add, the issue is just that some of the needed constructs are too hacky. I'll have a look to see if we can find alternate implementations that perform better.

[amir-arad]

@gcnew where are you quoting from? this book?