TypeScript began its life as an attempt to bring traditional object-oriented types\nto JavaScript so that the programmers at Microsoft could bring\ntraditional object-oriented programs to the web. As it has developed, TypeScript’s type\nsystem has evolved to model code written by native JavaScripters. The\nresulting system is powerful, interesting and messy.
\nThis introduction is designed for working Haskell or ML programmers\nwho want to learn TypeScript. It describes how the type system of\nTypeScript differs from Haskell’s type system. It also describes\nunique features of TypeScript’s type system that arise from its\nmodelling of JavaScript code.
\nThis introduction does not cover object-oriented programming. In\npractice, object-oriented programs in TypeScript are similar to those\nin other popular languages with OO features.
\nIn this introduction, I assume you know the following:
\nIf you need to learn the good parts of JavaScript, read\nJavaScript: The Good Parts.\nYou may be able to skip the book if you know how to write programs in\na call-by-value lexically scoped language with lots of mutability and\nnot much else.\nR4RS Scheme is a good example.
\nThe C++ Programming Language is\na good place to learn about C-style type syntax. Unlike C++,\nTypeScript uses postfix types, like so: x: string instead of string x.
JavaScript defines 7 built-in types:
\n| Type | \nExplanation | \n
|---|---|
Number | \na double-precision IEEE 754 floating point. | \n
String | \nan immutable UTF-16 string. | \n
Boolean | \ntrue and false. | \n
Symbol | \na unique value usually used as a key. | \n
Null | \nequivalent to the unit type. | \n
Undefined | \nalso equivalent to the unit type. | \n
Object | \nsimilar to records. | \n
See the MDN page for more detail.
\nTypeScript has corresponding primitive types for the built-in types:
\nnumberstringbooleansymbolnullundefinedobject| Type | \nExplanation | \n
|---|---|
unknown | \nthe top type. | \n
never | \nthe bottom type. | \n
| object literal | \neg { property: Type } | \n
void | \na subtype of undefined intended for use as a return type. | \n
T[] | \nmutable arrays, also written Array<T> | \n
[T, T] | \ntuples, which are fixed-length but mutable | \n
(t: T) => U | \nfunctions | \n
Notes:
\nFunction syntax includes parameter names. This is pretty hard to get used to!
\n\ntslet fst: (a: any, d: any) => any = (a, d) => a;\n// or more precisely:\nlet snd: <T, U>(a: T, d: U) => U = (a, d) => d.
Object literal type syntax closely mirrors object literal value syntax:
\n\ntslet o: { n: number; xs: object[] } = { n: 1, xs: [] };
[T, T] is a subtype of T[]. This is different than Haskell, where tuples are not related to lists.JavaScript has boxed equivalents of primitive types that contain the\nmethods that programmers associate with those types. TypeScript\nreflects this with, for example, the difference between the primitive\ntype number and the boxed type Number. The boxed types are rarely\nneeded, since their methods return primitives.
\nts(1).toExponential();\n// equivalent to\nNumber.prototype.toExponential.call(1);
Note that calling methods on numeric literals requires an additional\n. to aid the parser.
TypeScript uses the type any whenever it can’t tell what the type of\nan expression should be. Compared to Dynamic, calling any a type\nis an overstatement. It just turns off the type checker\nwherever it appears. For example, you can push any value into an\nany[] without marking the value in any way:
\nts// with \"noImplicitAny\": false in tsconfig.json, anys: any[]\nconst anys const anys: any[]= [];\nanys.const anys: any[]push((method) Array<any>.push(...items: any[]): number1);\nanys.const anys: any[]push((method) Array<any>.push(...items: any[]): number\"oh no\");\nanys.const anys: any[]push((method) Array<any>.push(...items: any[]): number{ anything:(property) anything: string\"goes\" });
And you can use an expression of type any anywhere:
\ntsanys.map(anys[1]); // oh no, \"oh no\" is not a function
any is contagious, too — if you initialise a variable with an\nexpression of type any, the variable has type any too.
\ntslet sepsis = anys[0] + anys[1]; // this could mean anything
To get an error when TypeScript produces an any, use\n\"noImplicitAny\": true, or \"strict\": true in tsconfig.json.
Structural typing is a familiar concept to most functional\nprogrammers, although Haskell and most MLs are not\nstructurally typed. Its basic form is pretty simple:
\n\nts// @strict: false\nlet o = { x: \"hi\", extra: 1 }; // ok\nlet o2: { x: string } = o; // ok
Here, the object literal { x: \"hi\", extra: 1 } has a matching\nliteral type { x: string, extra: number }. That\ntype is assignable to { x: string } since\nit has all the required properties and those properties have\nassignable types. The extra property doesn’t prevent assignment, it\njust makes it a subtype of { x: string }.
Named types just give a name to a type; for assignability purposes\nthere’s no difference between the type alias One and the interface\ntype Two below. They both have a property p: string. (Type alises\nbehave differently than interfaces with respect to recursive\ndefinitions and type parameters, however.)
\ntstype One type One = { p: string; }= { p:(property) p: string string };\ninterface Two interface Two\n p:(property) Two.p: string string;\n}\nclass Three class Three\n p (property) Three.p: string= \"Hello\";\n}\n\nlet x:let x: One One type One = { p: string; }= { p:(property) p: string\"hi\" };\nlet two:let two: Two Two interface Two= x;let x: One\ntwo let two: Two= new Three(constructor Three(): Three);
In TypeScript, union types are untagged. In other words, they are not\ndiscriminated unions like data in Haskell. However, you can often\ndiscriminate types in a union using built-in tags or other properties.
\ntsfunction start(function start(arg: string | string[] | (() => string) | { s: string; }): string\n arg:(parameter) arg: string | string[] | (() => string) | { s: string; } string | string[] | (() => string) | { s:(property) s: string string }\n): string {\n // this is super common in JavaScript\n if (typeof arg (parameter) arg: string | string[] | (() => string) | { s: string; }=== \"string\") {\n return commonCase((local function) commonCase(s: string): stringarg)(parameter) arg: string\n } else if (Array.var Array: ArrayConstructorisArray((method) ArrayConstructor.isArray(arg: any): arg is any[]arg)(parameter) arg: string[] | (() => string) | { s: string; }) {\n return arg.(parameter) arg: string[]map((method) Array<string>.map<string>(callbackfn: (value: string, index: number, array: string[]) => string, thisArg?: any): string[]commonCase)(local function) commonCase(s: string): string.join((method) Array<string>.join(separator?: string | undefined): string\",\");\n } else if (typeof arg (parameter) arg: (() => string) | { s: string; }=== \"function\") {\n return commonCase((local function) commonCase(s: string): stringarg((parameter) arg: () => string));\n } else {\n return commonCase((local function) commonCase(s: string): stringarg.(parameter) arg: { s: string; }s)(property) s: string\n }\n\n function commonCase((local function) commonCase(s: string): strings:(parameter) s: string string): string {\n // finally, just convert a string to another string\n return s;(parameter) s: string\n }\n}
string, Array and Function have built-in type predicates,\nconveniently leaving the object type for the else branch. It is\npossible, however, to generate unions that are difficult to\ndifferentiate at runtime. For new code, it’s best to build only\ndiscriminated unions.
The following types have built-in predicates:
\n| Type | \nPredicate | \n
|---|---|
| string | \ntypeof s === \"string\" | \n
| number | \ntypeof n === \"number\" | \n
| bigint | \ntypeof m === \"bigint\" | \n
| boolean | \ntypeof b === \"boolean\" | \n
| symbol | \ntypeof g === \"symbol\" | \n
| undefined | \ntypeof undefined === \"undefined\" | \n
| function | \ntypeof f === \"function\" | \n
| array | \nArray.isArray(a) | \n
| object | \ntypeof o === \"object\" | \n
Note that functions and arrays are objects at runtime, but have their\nown predicates.
\nIn addition to unions, TypeScript also has intersections:
\n\ntstype Combined type Combined = { a: number; } & { b: string; }= { a:(property) a: number number } & { b:(property) b: string string };\ntype Conflicting type Conflicting = { a: number; } & { a: string; }= { a:(property) a: number number } & { a:(property) a: string string };
Combined has two properties, a and b, just as if they had been\nwritten as one object literal type. Intersection and union are\nrecursive in case of conflicts, so Conflicting.a: number & string.
Unit types are subtypes of primitive types that contain exactly one\nprimitive value. For example, the string \"foo\" has the type\n\"foo\". Since JavaScript has no built-in enums, it is common to use a set of\nwell-known strings instead. Unions of string literal types allow\nTypeScript to type this pattern:
\ntsdeclare function pad(function pad(s: string, n: number, direction: "left" | "right"): strings:(parameter) s: string string, n:(parameter) n: number number, direction:(parameter) direction: "left" | "right"\"left\" | \"right\"): string;\npad(function pad(s: string, n: number, direction: "left" | "right"): string\"hi\", 10, \"left\");
When needed, the compiler widens — converts to a\nsupertype — the unit type to the primitive type, such as \"foo\"\nto string. This happens when using mutability, which can hamper some\nuses of mutable variables:
\ntslet s = \"right\";\npad(\"hi\", 10, s); // error: 'string' is not assignable to '\"left\" | \"right\"'
Here’s how the error happens:
\n\"right\": \"right\"s: string because \"right\" widens to string on assignment to a mutable variable.string is not assignable to \"left\" | \"right\"You can work around this with a type annotation for s, but that\nin turn prevents assignments to s of variables that are not of type\n\"left\" | \"right\".
\ntslet s: \"left\" | \"right\" = \"right\";\npad(\"hi\", 10, s);
TypeScript has some obvious places where it can infer types, like\nvariable declarations:
\n\ntslet s let s: string= \"I'm a string!\";
But it also infers types in a few other places that you may not expect\nif you’ve worked with other C-syntax languages:
\n\ntsdeclare function map<function map<T, U>(f: (t: T) => U, ts: T[]): U[]T,(type parameter) T in map<T, U>(f: (t: T) => U, ts: T[]): U[] U>(type parameter) U in map<T, U>(f: (t: T) => U, ts: T[]): U[](f:(parameter) f: (t: T) => U (t:(parameter) t: T T)(type parameter) T in map<T, U>(f: (t: T) => U, ts: T[]): U[]=> U,(type parameter) U in map<T, U>(f: (t: T) => U, ts: T[]): U[] ts:(parameter) ts: T[] T[(type parameter) T in map<T, U>(f: (t: T) => U, ts: T[]): U[]]): U[(type parameter) U in map<T, U>(f: (t: T) => U, ts: T[]): U[]];\nlet sns let sns: string[]= map(function map<number, string>(f: (t: number) => string, ts: number[]): string[]n (parameter) n: number=> n.(parameter) n: numbertoString((method) Number.toString(radix?: number | undefined): string), [1, 2, 3]);
Here, n: number in this example also, despite the fact that T and U\nhave not been inferred before the call. In fact, after [1,2,3] has\nbeen used to infer T=number, the return type of n => n.toString()\nis used to infer U=string, causing sns to have the type\nstring[].
Note that inference will work in any order, but intellisense will only\nwork left-to-right, so TypeScript prefers to declare map with the\narray first:
\ntsdeclare function map<function map<T, U>(ts: T[], f: (t: T) => U): U[]T,(type parameter) T in map<T, U>(ts: T[], f: (t: T) => U): U[] U>(type parameter) U in map<T, U>(ts: T[], f: (t: T) => U): U[](ts:(parameter) ts: T[] T[(type parameter) T in map<T, U>(ts: T[], f: (t: T) => U): U[]], f:(parameter) f: (t: T) => U (t:(parameter) t: T T)(type parameter) T in map<T, U>(ts: T[], f: (t: T) => U): U[]=> U)(type parameter) U in map<T, U>(ts: T[], f: (t: T) => U): U[]: U[(type parameter) U in map<T, U>(ts: T[], f: (t: T) => U): U[]];
Contextual typing also works recursively through object literals, and\non unit types that would otherwise be inferred as string or\nnumber. And it can infer return types from context:
\ntsdeclare function run<function run<T>(thunk: (t: T) => void): TT>(type parameter) T in run<T>(thunk: (t: T) => void): T(thunk:(parameter) thunk: (t: T) => void (t:(parameter) t: T T)(type parameter) T in run<T>(thunk: (t: T) => void): T=> void): T;(type parameter) T in run<T>(thunk: (t: T) => void): T\nlet i:let i: { inference: string; } { inference:(property) inference: string string } = run(function run<{ inference: string; }>(thunk: (t: { inference: string; }) => void): { inference: string; }o (parameter) o: { inference: string; }=> {\n o.(parameter) o: { inference: string; }inference (property) inference: string= \"INSERT STATE HERE\";\n});
The type of o is determined to be { inference: string } because
{ inference: string }.T={ inference: string }.o: { inference: string }.And it does so while you are typing, so that after typing o., you\nget completions for the property inference, along with any other\nproperties you’d have in a real program.\nAltogether, this feature can make TypeScript’s inference look a bit\nlike a unifying type inference engine, but it is not.
Type aliases are mere aliases, just like type in Haskell. The\ncompiler will attempt to use the alias name wherever it was used in\nthe source code, but does not always succeed.
\ntstype Size type Size = [number, number]= [number, number];\nlet x:let x: Size Size type Size = [number, number]= [101.1, 999.9];
The closest equivalent to newtype is a tagged intersection:
\ntstype FString = string & { __compileTimeOnly: any };
An FString is just like a normal string, except that the compiler\nthinks it has a property named __compileTimeOnly that doesn’t\nactually exist. This means that FString can still be assigned to\nstring, but not the other way round.
The closest equivalent to data is a union of types with discriminant\nproperties, normally called discriminated unions in TypeScript:
\ntstype Shape =\n | { kind: \"circle\"; radius: number }\n | { kind: \"square\"; x: number }\n | { kind: \"triangle\"; x: number; y: number };
Unlike Haskell, the tag, or discriminant, is just a property in each\nobject type. Each variant has an identical property with a different\nunit type. This is still a normal union type; the leading | is\nan optional part of the union type syntax. You can discriminate the\nmembers of the union using normal JavaScript code:
\ntstype Shape type Shape = { kind: "circle"; radius: number; } | { kind: "square"; x: number; } | { kind: "triangle"; x: number; y: number; }\n | { kind:(property) kind: "circle"\"circle\"; radius:(property) radius: number number }\n | { kind:(property) kind: "square"\"square\"; x:(property) x: number number }\n | { kind:(property) kind: "triangle"\"triangle\"; x:(property) x: number number; y:(property) y: number number };\n\nfunction area(function area(s: Shape): numbers:(parameter) s: Shape Shape)type Shape = { kind: "circle"; radius: number; } | { kind: "square"; x: number; } | { kind: "triangle"; x: number; y: number; } {\n if (s.(parameter) s: Shapekind (property) kind: "circle" | "square" | "triangle"=== \"circle\") {\n return Math.var Math: MathPI (property) Math.PI: number* s.(parameter) s: { kind: "circle"; radius: number; }radius (property) radius: number* s.(parameter) s: { kind: "circle"; radius: number; }radius;(property) radius: number\n } else if (s.(parameter) s: { kind: "square"; x: number; } | { kind: "triangle"; x: number; y: number; }kind (property) kind: "square" | "triangle"=== \"square\") {\n return s.(parameter) s: { kind: "square"; x: number; }x (property) x: number* s.(parameter) s: { kind: "square"; x: number; }x;(property) x: number\n } else {\n return (s.(parameter) s: { kind: "triangle"; x: number; y: number; }x (property) x: number* s.(parameter) s: { kind: "triangle"; x: number; y: number; }y)(property) y: number / 2;\n }\n}
Note that the return type is area is inferred to be number because\nTypeScript knows the function is total. If some variant is not\ncovered, the return type of area will be number | undefined instead.
Also unlike Haskell, common properties show up in any union, so you\ncan usefully discriminate multiple members of the union:
\n\ntsfunction height(s: Shape) {\n if (s.kind === \"circle\") {\n return 2 * s.radius;\n } else {\n // s.kind: \"square\" | \"triangle\"\n return s.x;\n }\n}
Like most C-descended languages, TypeScript requires declaration of\ntype parameters:
\n\ntsfunction liftArray<T>(t: T): Array<T> {\n return [t];\n}
There is no case requirement, but type parameters are conventionally\nsingle uppercase letters. Type parameters can also be constrained to a\ntype, which behaves a bit like type class constraints:
\n\ntsfunction firstish<T extends { length: number }>(t1: T, t2: T): T {\n return t1.length > t2.length ? t1 : t2;\n}
TypeScript can usually infer type arguments from a call based on the\ntype of the arguments, so type arguments are usually not needed.
\nBecause TypeScript is structural, it doesn’t need type parameters as\nmuch as nominal systems. Specifically, they are not needed to make a\nfunction polymorphic. Type parameters should only be used to\npropagate type information, such as constraining parameters to be\nthe same type:
\n\ntsfunction length<T extends ArrayLike<unknown>>(t: T): number {}\n\nfunction length(t: ArrayLike<unknown>): number {}
In the first length, T is not necessary; notice that it’s only\nreferenced once, so it’s not being used to constrain the type of the\nreturn value or other parameters.
TypeScript does not have higher kinded types, so the following is not legal:
\n\ntsfunction length<T extends ArrayLike<unknown>, U>(m: T<U>) {}
Point-free programming — heavy use of currying and function\ncomposition — is possible in JavaScript, but can be verbose.\nIn TypeScript, type inference often fails for point-free programs, so\nyou’ll end up specifying type parameters instead of value parameters. The\nresult is so verbose that it’s usually better to avoid point-free\nprogramming.
\nJavaScript’s modern module syntax is a bit like Haskell’s, except that\nany file with import or export is implicitly a module:
\ntsimport { value, Type } from \"npm-package\";\nimport { other, Types } from \"./local-package\";\nimport * as prefix from \"../lib/third-package\";
You can also import commonjs modules — modules written using node.js’\nmodule system:
\n\ntsimport f = require(\"single-function-package\");
You can export with an export list:
\n\ntsexport { f };\n\nfunction f() {\n return g();\n}\nfunction g() {} // g is not exported
Or by marking each export individually:
\n\ntsexport function f { return g() }\nfunction g() { }
The latter style is more common but both are allowed, even in the same\nfile.
\nreadonly and constIn JavaScript, mutability is the default, although it allows variable\ndeclarations with const to declare that the reference is\nimmutable. The referent is still mutable:
\njsconst a = [1, 2, 3];\na.push(102); // ):\na[0] = 101; // D:
TypeScript additionally has a readonly modifier for properties.
\ntsinterface Rx {\n readonly x: number;\n}\nlet rx: Rx = { x: 1 };\nrx.x = 12; // error
It also ships with a mapped type Readonly<T> that makes\nall properties readonly:
\ntsinterface X {\n x: number;\n}\nlet rx: Readonly<X> = { x: 1 };\nrx.x = 12; // error
And it has a specific ReadonlyArray<T> type that removes\nside-affecting methods and prevents writing to indices of the array,\nas well as special syntax for this type:
\ntslet a: ReadonlyArray<number> = [1, 2, 3];\nlet b: readonly number[] = [1, 2, 3];\na.push(102); // error\nb[0] = 101; // error
You can also use a const-assertion, which operates on arrays and\nobject literals:
\n\ntslet a = [1, 2, 3] as const;\na.push(102); // error\na[0] = 101; // error
However, none of these options are the default, so they are not\nconsistently used in TypeScript code.
","headings":[{"value":"Prerequisites","depth":1},{"value":"Concepts not in Haskell","depth":1},{"value":"Built-in types","depth":2},{"value":"Other important Typescript types","depth":3},{"value":"Boxed types","depth":3},{"value":"Gradual typing","depth":2},{"value":"Structural typing","depth":2},{"value":"Unions","depth":2},{"value":"Intersections","depth":3},{"value":"Unit types","depth":2},{"value":"Concepts similar to Haskell","depth":1},{"value":"Contextual typing","depth":2},{"value":"Type aliases","depth":2},{"value":"Discriminated Unions","depth":2},{"value":"Type Parameters","depth":2},{"value":"Higher-kinded types","depth":3},{"value":"Point-free programming","depth":3},{"value":"Module system","depth":2},{"value":"readonly and const","depth":2}],"frontmatter":{"permalink":"/docs/handbook/typescript-in-5-minutes-func.html","title":"TypeScript for Functional Programmers"}}},"pageContext":{"slug":"/docs/handbook/typescript-in-5-minutes-func.html","isOldHandbook":true}}}