Pattern Matching Support

[dignifiedquire]

I've seen some short notions about pattern matching on code plex, but no serious discussions around it. As I'm a big fan of it, I've written up some small examples on how I think pattern matching could look in TypeScript.

This is by far no complete specification, just some ideas that I want to bring forward and have a little discussion around.

Function Overloading

// Pattern matching on functions

function pickCard {
  (x: {suit: string; card: number; }[]): number {

    var pickedCard = Math.floor(Math.random() * x.length);
    return pickedCard;  

  }
  (x: number): {suit: string; card: number; } {

    var pickedSuit = Math.floor(x / 13);
    return { suit: suits[pickedSuit], card: x % 13 };

  }
} 

// Translation of functions.ts using sparkler
// https://github.com/natefaubion/sparkler

function pickCard(x) {
  [...{ suit @ String, card @ number }] =>  {
    var pickedCard = Math.floor(Math.random() * x.length);
    return pickedCard;  
  }
  x @ Number => {
    var pickedSuit = Math.floor(x / 13);
    return { suit: suits[pickedSuit], card: x % 13 };
  }
} 

Match statement

// Pattern matching using match

function whoami (x: any): string {

  match x {
    case { name: string, type: 'person' }: 
        return 'Person: ' + name;

    case { name: string, type: 'animal' }: 
        return 'Animal: ' + name;

    default: 
        return 'Unkown you';
  }
} 

// Pattern matching using match translated

function whoami (x) {

  match x {
    case { name @ String, type: 'person' }: 
        return 'Person: ' + name;

    case { name @ String, type: 'animal' }: 
        return 'Animal: ' + name;

    default: 
        return 'Unkown you';
  }

} 

[RyanCavanaugh]

We've typically avoided features that require type information at runtime, because many types in TypeScript are indistinguishable from a runtime perspective.

For example, what would the emitted JavaScript look like in this case?

enum Suit { Spades, Hearts, Clubs, Diamonds }
enum Rank { Ace, King, Queen, Jack }
function pickCard {
    (s: Suit) : number { return 1; }
    (r: Rank): number { return 0; }
}

pickCard(Suit.Spades);
pickCard(undefined);

[justinmchase]

@RyanCavanaugh You could potentially build in an Ometa-like library that allowed you to do pattern matching of all sorts. You may want a more TS friendly syntax but it would be very compelling. You could do matching on any object not just Types. Here's an example
http://www.tinlizzie.org/ometa-js/#Typechecker

[AlexGalays]

"We've typically avoided features that require type information at runtime"

Will that change with the accommodating of the angular2 reflection?

[mhegazy]

@AlexGalays, i do not think so. one thing we are trying to maintain is keep a single module transpilation possible with no semantic information present.

[refi64]

I have to say, something like this would be insanely nice. What are the chances of this happening?

[SamuelMarks]

👍

[dev-tim]

👍

[svanderbleek]

👍

[slavah]

👍

[tejacques]

Just wanted to point out a possible alternative that may be available with --noImplicitReturns with the modification mentioned here #5916.

This gets you code that looks like this, and requires no changes to TypeScript whatsoever

interface SomeType {
    stringValue: string
}

function isSomeType(x: any): x is SomeType {
    return x && typeof(x.stringValue) === 'string';
}

function foo(x: number | string | boolean | SomeType): string {
    if(typeof x === 'number' || typeof x === 'boolean') {
        return x.toString();
    } else if (typeof x === 'string') {
        return x;
    } else if (isSomeType(x)) {
        return x.stringValue;
    } else {
        return 'other';
    }
}

--noImplicitReturns gives us full spectrum matching in a very conventionally JavaScript way. We can now make a pretty trivial helper function match:

function match<T, U>(value: T, matcher: (t: T) => U) {
    return matcher(value);
}

And we can use it like this:

const res = match(1, (x: string | boolean | number | SomeType): string => {
    if(typeof x === 'number' || typeof x === 'boolean') {
        return x.toString();
    } else if (typeof x === 'string') {
        return x;
    } else if (isSomeType(x)) {
        return x.stringValue;
    } else {
        return 'other';
    }
});

and

const value: string | boolean | number | SomeType = 5;
const res = match(value, x => {
    if(typeof x === 'number' || typeof x === 'boolean') {
        return x.toString();
    } else if (typeof x === 'string') {
        return x;
    } else if (isSomeType(x)) {
        return x.stringValue;
    } else {
        return 'other';
    }
});

With full safety that we have handled all cases in the union.

New proposal for syntactic sugar

Make match a built-in construct which would look like this:

A language construct that takes an object mapping the type (property name) to a function or literal.

const res = match (value) {
    string: s => s,
    boolean: b => b.toString,
    number: n => n.toString(),
    SomeType({ stringValue }) { return stringValue },
    default: 'other'
}

All that's happening here is it creates a function for you that creates an if(isType(value)) return typeFn(value) statement, for each function passed in. For primitive types, it uses: typeof (value) === '<primitive>', for "tagged" or disjoint unions specified with type literals, the field containing the literal type could be checked, and for any other type, it checks to see if a function is<Type> exists in scope.

So this maps out to the following code:

const res = ((x: string | boolean | number | SomeType): string => {
    if (typeof x === 'string') {
        return ((s: string) => s)(x);
    } else if (typeof x === 'boolean') {
        return ((b: boolean) => b.toString())(x);
    } else if(typeof x === 'number') {
        return ((n: number) => n.toString())(x);    
    } else if (isSomeType(x)) {
        return (({ stringValue }: SomeType) => stringValue)(x);
    } else {
        return 'other';
    }
})(value);

This somewhat addresses @RyanCavanaugh's concern about enum types or other things which have their type information erased at runtime in the sense that because no isSuit or isRank type guard exists in scope, it would give a compiler error. It could also conceivably give a compiler error in the case of overlapping type literals, since all their values are known at compile time.

As an optimization, if the type being matched on is purely composed of a "tagged"/disjoint union based on type literals, it could output the following:

type Circle = {
    shape: 'square'
    radius: number
}
type Rectangle = {
    shape: 'rectangle'
    length: number
    width: number
}
type Square = {
    shape: 'square'
    length: number
}

// because these have a shared literal property
// that will be used as the implicit "tag", and TS
// can know this is a tagged union
type Shape = Circle | Rectangle | Square

const shape: Shape = getShape(); // some shape
function getArea(shape: Shape) {
    return match shape {
        Circle: ({ radius }) => 3.14 * (radius * radius),
        Rectangle: ({ length, width }) => length * width,
        Square: ({ length }) => length * length,
    };
}

The getArea function would be translated in an optimized way to look like this:

function getArea(shape: Shape) {
    return ({
        /* Circle.shape literal    */ 'circle': ({ radius }) => 3.14 * (radius * radius),
        /* Rectangle.shape literal */ 'rectangle': ({ length, width }) => length * width,
        /* Square.shape literal    */ 'square': ({ length }) => length * length,
    })[shape.shape](shape);
}

👍

But why not erlang style function guards? The syntax proposed above is a little funky.

function animal(species: Cat) {
    species.meow();
}

function animal(species: Dog) {
    species.bark();
}

becomes:

function animal(species: Cat | Dog) {
    if (species instanceof Cat) {
        species.meow();
    } else if (species instanceof Dog) {
        species.bark();
    }
}

or checking values:

function animal(alive: true) : string {
    return "Is alive";
}

function animal(alive: false) : string {
    return "Is not alive";
}

[felixSchl]

Personally, I wouldn't call it funky, since it's pretty common (i.e. found a lot of adoption). Here's a incomplete list of languages that come to mind:

• rust
• haskell (see section 4.3)
• purescript
• fsharp
• ocaml
• scala

There are ought to be plenty more, those just came to the top of my head.

You can check values using guards then, i.e. case x:xs | x == 0 to check if this is a list where the first element is a 0.

Your suggestions reminds me of multi-methods in lisp or function lookup based on arity like in elixir.