Skip to content
This repository was archived by the owner on Oct 12, 2022. It is now read-only.

Remove "algebraic data types" #662

Closed
wants to merge 1 commit into from
Closed

Conversation

bsima
Copy link

@bsima bsima commented Oct 11, 2017

This is incorrect. A tagged union is one way to implement sum types, which is a kind of algebraic data type. However, product types (another common ADT) is not possible in TypeScript.

This is incorrect. A tagged union is one way to implement sum types, which is a kind of algebraic data type. However, product types (another common ADT) is not possible in TypeScript.
@heejongahn
Copy link

+1 for more correct documentation. However, TypeScript supports a tuple type. Isn't that a product type?

@DanielRosenwasser
Copy link
Member

Tuple types and record types (i.e. objects) are both product types, so I'm not even sure if the pedantry here is correct. ;)

@bsima
Copy link
Author

bsima commented Oct 25, 2017

The pedantry is correct because a tagged union is an ADT but not all ADTs are tagged unions. The documentation will be more understandable with concrete descriptions and explanations, not with grand claims about general support. Let me explain with an example.

In Typescript this is a union type:

type Thing =
  | Widget
  | Gadget;

whereas in other languages such as Elm a similar syntax is a sum type. In order to get the effect of sum types with tagged unions, you have to manually specify the tags; in other ML-derived languages the compiler does this for you. (Note that tagged unions and sum types are not really the same thing. microsoft/TypeScript#186 was opened asking for sum types and closed with the addition of tagged unions, to some users' dismay.)

This is a source of confusion for people coming from other ML-derived languages. I'm trying to make this clearer for people coming from these languages. Saying that TS supports ADT's implies that the compiler handles this for you, but in reality TS has as much support for ADT's as Lisp (yeah you can implement these types with raw lists and macros, but you need to put in a lot more work than you do in Haskell/Elm).

Maybe it would make more sense to describe TS types in the context of ML, and give common alternatives and patterns, rather than just a generalized "TS supports ADTs" claim.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants