Generic values

[masaeedu]

TypeScript supports generic type/interface/class declarations. These features serve as an analog of "type constructors" in other type systems: they allow us to declare a type that is parameterized over some number of type arguments.

TypeScript also supports generic functions. These serve as limited form of parametric polymorphism: they allow us to declare types whose inhabitants are parametrized over some number of type arguments. Unlike in certain other type systems however, these types can only be function types.

So for example while we can declare:

type Id = <T>(x : T) => T

const test : Id = x => x

we cannot declare (for whatever reason):

type TwoIds = <T> { id1: (x: T) => T, id2: (x: T) => T }

const test : TwoIds = { id1: x => x, id2: x => x }

One result of this limitation is that the type constructor and polymorphism features interact poorly in TypeScript. The problem applies even to function types: if we abstract a sophisticated function type into a type constructor, we can no longer universally quantify away its type parameters to get a generic function type. This is illustrated below:

// This works
type Id = <T>(x : T) => T

// This should also work
type IdT<T> = (x: T) => T
type Id = <T> IdT<T> // but is impossible to express

Another problem is that it is often useful to quantify over types other than bare functions, and TypeScript prohibits this. As an example, this prevents us from modeling polymorphic lenses:

type Lens<T, U> = {
    get(obj: T): U
    set(val: U, obj: T): T
}

// no way to express the following type signature
const firstItemInArrayLens: <A> Lens<A[], A> = {
    get: arr => arr[0],
    set: (val, arr) => [val, ...arr.slice(1)]
}

firstItemInArrayLens.get([10])      // Should be number
firstItemInArrayLens.get(["Hello"]) // Should be string

In this case, a workaround is to break down the type into functions and move all the polymorphic quantification there, since functions are the only values that are allowed to be polymorphic in TypeScript:

type ArrayIndexLens = {
    get<A>(obj: A[]): A
    set<A>(val: A, obj: A[]): A[]
}

const firstItemInArrayLens: ArrayIndexLens = { ... }

By contrast, in Haskell you'd simply declare an inhabitant of a polymorphic type: firstItemInArrayLens :: forall a. Lens [a] a, similarly to the pseudocode declaration const firstItemInArrayLens: <A> Lens<A[], A>:

{-# LANGUAGE ExplicitForAll #-}

data Lens s a = Lens { get :: s -> a, set :: a -> s -> s }

firstItemInArrayLens :: forall a. Lens [a] a
firstItemInArrayLens = Lens { get = _, set = _ }

In some sense TypeScript has even less of a problem doing this than Haskell, because Haskell has concerns like runtime specialization; it must turn every polymorphic expression into an actual function which receives type arguments.

TypeScript just needs to worry about assignability; at runtime everything is duck typed and "polymorphic" anyway. A more polymorphic term (or a term for which a sufficiently polymorphic type can be inferred) can be assigned to a reference of a less polymorphic type.

Today, a value of type <A> (x: A) => A is assignable where a (x: number) => number is expected, and in turn the expression x => x is assignable where a <A> (x: A) => A is expected. Why not generalize this so an <A> Foo<A> is assignable wherever a Foo<string> is expected, and it is possible to write: const anythingFooer: <A> Foo<A> = { /* implement Foo polymorphically */ }?

[HerringtonDarkholme]

As a comparison, flow supports similar feature by wildcard type.

// @flow

type Lens<T, U> = {
    get(obj: T): U,
    set(val: U, obj: T): T
}

// use wildcard
const firstItemInArrayLens: Lens<*[], *> = {
    get: arr => arr[0],
    set: (val, arr) => [val, ...arr.slice(1)]
}

firstItemInArrayLens.get([10])      //  is number
firstItemInArrayLens.get(["Hello"]) //  is string

[masaeedu]

@HerringtonDarkholme Interesting. If I wanted to express Lens<A, B>, where A and B are allowed to vary independently (i.e. Lens<number, string[]> is allowed), how would flow express that with wildcards?

With the proposal above I'd just have <A, B> Lens<A, B>.

[HerringtonDarkholme]

I guess by default flow will treat wildcard as different type parameters. So two independent varying parameter is the default behavior. The real problem of wildcard is their inter-dependence and bound. For example type like ADependsB<A, B extends A> is hard to express in wildcard. (I guess, flow type sadly does not have official doc for wildcard type.)

Generic value of course is a better proposal. I just want to list other type checkers' attitude toward similar features.

[snewell92]

I think I found another use for this, let's say I want to have a function that takes in a predicate, and returns the second param wrapped in a box if true, and the third param wrapped in the same box if false. The things you shove in the box can be different types, something like this (with Task from folktale 2 as our box):

export type Predicate = () => true | false;
type TestTask = <T>(pred: Predicate, ofTask: T, errTask: any) => Task<T>

// invoke constructors of Task, or some factory function, or perhaps pass those in
const testToTask: <T> TestTask<T> = (p, o ,e) => p() ? of(0) : rejected(e);

But instead I need to do

const testToTask: <V>(p: Predicate, ofTask: V, errTask: any) => Task<V> =
  (p, o, e) => p() ? of(o) : rejected(e);

calling it would look like (with folktale2 tasks):

let isValidUser = user => () => user != null && user.email != null && user.email.length > 0;


testToTask(isValidUser(user), user, 'Invalid')
  .map(user => user.email)
  .chain(doSomethingElseAsyncWithEmail)
  .run()
  .promise()

In fact, I'm running into several scenarios where this kind of pattern would be helpful in making some generalized function, but I can't succinctly type it.

[masaeedu]

Implementing things like Maybe is also inconvenient without generic values; you want the types of the constructors to be Just :: a -> Maybe a and Nothing :: Maybe a. That is, Nothing should be a value is acceptable wherever a Maybe String is wanted, as well as where a Maybe Number is wanted (but not, for example, where a String is wanted).

[matthias-ccri]

I have a need for this as well. Using React, I have a Higher-Order Component that takes a ComponentClass and additional props for that component. I'd like to write an interface that infers its generic from the values of the object, like this:

interface IComponentForHOC <P> {
    component: React.ComponentClass<P> // <-- inferring P from here
    additionalProps: Partial<P>
}

And I'd use this interface to enforce that I'm passing the right props for whatever component I pass:

class Marker extends React.Component<{
    // Props -- the HOC will provide `x`, but `color` needs to be specified.
    x: number, 
    color: string
}> { /* ... */}

// Then Marker is passed to the HOC, which renders it, passing some props 
// as well as `additionalProps`. 
return <PositionerHOC 
            objects={[
                {
                    component: Marker, 
                    additionalProps: {color: 'midnightblue'},
                },
            ]}
        />

So, that's my use case. I realize I can work around it for now with a function wrapper (below), but that's not ideal. Anyway, I hope to see this feature soon!

function createHOCObject <P>(
    component: React.Component<P>, 
    additionalProps: Exclude<P, keyof PropsFromHOC>
): HOCObject<P> {
    return { component, additionalProps }
}

[simonbuchan]

As stated, this wouldn't allow heterogeneous collections? E.g. in const arrayLenses: <A> Array<Lens<A[], A>> , all the items have the same A? Syntactically you could allow Array<<A> Lens<A[], A>>, but I'm not sure there's a good way to deal with that (e.g. the type of arrayLenses[0] would have to have a fresh A in each evaluation somehow).

I often find myself wanting to use a plugin-registration pattern, something like e.g.:

interface Plugin<Config, Props, State extends Storable> {
  parseConfig(source: string): Config;
  initialState(config: Config): State;
  getProps(config: Config, state: State): Props;
  render(props: Props): ReactNode;
  // ...
}

const plugins: Array<Plugin<???>> = []; // is this a "generic value"?

where the code using the type only cares that the result of plugin.parseConfig() can be passed to plugin.initialState() for the same item. For now I've been using <any>, but that allows passing config as state, etc., in the using code, which sucks.

I've been thinking of this as type Plugin = <Config, Props, State> { ... }, e.g. allow adding generic parameters to any type expression, which I think also covers the original suggestion, is that generalization problematic?

[masaeedu]

@simonbuchan That's an orthogonal concern. If you wanted to write a polymorphic function that can work with heterogeneous arrays, you wouldn't write it as:

const f = <A>(a: A[]) => ...

but as:

const f = <A extends {}[]>(a: A) => ...

That principle would remain unchanged when talking about polymorphic values besides functions that involve heterogeneous arrays.

Regarding your proposal of type Plugin = <Config, Props, State> { ... }, I'm not really sure how this is different from what's already been proposed. The original proposal is to make it possible to introduce existential quantifiers at the head of arbitrary type expressions instead of just allowing it at the head of function types.

Today I can write:

const id: /* for all A */ <A> /* a function from A to A */ (a: A) => A = x => x

But I can't simply move that one level out and write:

const o: <A> { id: (a: A) => A } = { id: x => x }

If the feature were added that allows me to be able to write that type annotation I can obviously move things around and put them in type aliases, i.e. have type ObjWithIdProp = <A> { id: (a: A) => A } and then const o: ObjWithIdProp = { id: x => x }, just as you could write type Id = <A>(a: A) => A and then const id: Id = x => x. This is the same as the original proposal, not a generalization of it.