Object-oriented languages (including JavaScript) have primitive support for dynamic dispatch, which automatically chooses the best method to invoke at run time, based on the class of the receiver. You made use of this feature to good effect in the Interpreter assignments. For example, the eval You may have used a different name, e.g., interp. method of a BinOp AST node can simply invoke this.e1.eval(…) to recursively evaluate its first operand, without having to manually figure out the right eval method implementation for it; rather, each kind of node just “knows” how to evaluate itself.

Including the language you implemented in Assignment 6. However, dynamic dispatch has some important limitations when compared to a general mechanism for pattern matching, as supported by many functional languages:

• Dynamic dispatch can only be used at the “top level” of a method, to determine which method implementation to invoke. For example, suppose the code for the method described above needs to behave differently based on the kind of value v that is returned by the call this.e1.eval(…). To use dynamic dispatch, our only option is to create a new method evalHelper with implementations for each kind of value, and invoke v.evalHelper() inside BinOp’s implementation of eval. This approach is heavyweight and breaks up the logic of the original method in a potentially unnatural way — so much so that it is common for programmers to instead resort to manual dispatch through instanceof tests.
• Dynamic dispatch does not support many useful features of pattern matching, such as “deep” pattern matching on the structure of an object and tests on primitive values (e.g., an integer that is equal to 5).
• In a language that supports single dispatch … as opposed to multiple-dispatch. — the majority of mainstream OO languages! — dynamic dispatch only gives programmers a declarative way to implement different behaviors based on the class of the receiver. There is no easy way to dispatch based on the classes of the arguments of a method.

Of course, one solution to this problem is to simply switch to Ha language that already supports pattern matching, like the one you implemented in Assignment 6. But changing languages is not always an option:

• It may be that you’re using several libraries that are only available in JavaScript (or whatever language you are currently using), and it’s too much effort to reimplement all of that functionality in another language;
• You may also be using several tools that are tightly coupled with JavaScript, such as a special development environment, debugger, etc. There is a high cost to losing all of these tools and having to find appropriate replacements.
• By “obscure” we mean anything that’s not Java or C++… maybe C#, too. Or maybe your boss isn’t happy with the idea of an “obscure” language creeping into the company’s code base, because you’ll eventually move on and she will have to find someone else who can maintain the code. This kind of thing is a real concern in industry.

An increasingly popular solution to this problem is to provide the desired abstraction in the form of an internal domain-specific language (DSL). This name is important, so let’s break it down:

• Internal means that it lives inside a host language, as opposed to being a language that you can use on its own.
• Domain-specific means that it’s focused on a particular problem, as opposed to general-purpose.

Internal DSLs (usually) don’t have their own syntax; instead they have a carefully-designed API in the host language that feels somewhat natural to write, and makes for readable code. Designing such an API is not easy, and some host languages are better than others. Smalltalk, Ruby, Haskell, and Scala are all reasonably good host languages. C not so much, though its macro system can be used to implement some limited kinds of DSLs. Java is basically awful as a host language.

So what should you look for in a host language?

• It helps if the language is expression-oriented, i.e., if nearly everything the programmer ever writes is an expression that yields a value. The uniformity of this style of language makes it easier to extend, in contrast to a language that has rigid distinctions among different syntactic categories (e.g., between expressions and statements).
• Support for first-class functions, especially if the syntax is lightweight. First-class functions are critical for implementing new control structures, new kinds of modularity mechanisms, and more. See the original Lambda the Ultimate… papers for good examples of this kind of thing.
• Operator overloading. If you were using an internal DSL for matrix arithmetic, would you rather have to write aMatrix.times(anotherMatrix) or aMatrix * anotherMatrix?
• Garbage collection and finalizers make it possible for the implementation of a DSL to clean up after itself (deallocate data structures, close files, etc.) without burdening the programmer.

Note: if you didn't lose any points in Assignment 2, you are not required to do Part I (I think this only applies to one project in the class). For Part I of Assignment 8, you will revise your concept-based language design from Assignment 2 to fix any issues identified in the feedback you received. You will have a chance to regain any points you lost in Assignment 2.

For Part II of Assignment 8, you’ll implement an internal DSL for pattern matching in JavaScript. Here’s an example of how this DSL could be used to implement a zip function, which turns two lists into a list of pairs, assuming we have declared classes Nil and Cons to implement linked lists: function zip(l1, l2) { return match([l1, l2], [instof(Nil), instof(Nil)], () => new Nil(), [instof(Cons,_,_), instof(Cons,_,_)], (x, xs, y, ys) => new Cons([x,y], zip(xs,ys)) ); } Pattern matching with this DSL may not be as nice as doing it in a language that has native support for pattern matching, but it sure beats deconstructing the objects manually. The resulting code is both more readable (once you get used to the syntax) and less error-prone.

Description of the DSL

The match function

Our DSL consists of a match function whose arguments are a value to be matched, followed by zero or more (pattern, function) pairs: match(value, pat1, fun1, pat2, fun2, …) match will try to match the value with each of the patterns, in left-to-right order. When it finds the first pattern that matches the value, match will call that pattern’s corresponding function and return the result of that call. If none of the patterns match the value, match will throw an exception like this: throw new Error('match failed');

Patterns

A pattern in our DSL serves two purposes:

• It tells you whether it matches a value.
• A function’s length property tells you the number of arguments it expects. E.g., ((x, y) => x + y).length evaluates to 2. On a successful match, it also breaks down the value into zero or more bindings that will be passed as arguments to the pattern’s corresponding function. Note that the arity (i.e., the number of arguments) of this function must be the same as the number of bindings generated by the pattern. Important: your implementation should throw an exception if this is not the case.

Here is a list of the patterns that are supported in our DSL:

• The wildcard pattern _ matches any value, and produces a single binding that is equal to that value.
• An array of patterns can also be used as a pattern. The array pattern [p₁, p₂, …, p_n] will match any array whose contents are matched by p₁, p₂, …, p_n, and if so, it will produce all of the bindings that were produced by its sub-patterns, in order. For example:

  match(['+', 5, 7], ['+', _, _], (x, y) => x + y )	evaluates to 12.
  match(['+', 5], ['+', _, _], (x, y) => x + y )	throws a match failed exception because there is no value to be matched by the second _ pattern.
  match(['+', 5, 7], ['+', _], (x) => x )	throws a match failed exception because there is no pattern to match the 7.

• The predicate pattern pred(f), where f is a one-argument function, matches any value v for which f(v) is A value v is truthy if v == true. truthy. On a successful match, a predicate pattern produces a single binding that is equal to the value that was matched. For example, if isNumber is defined as follows, function isNumber(x) { return typeof x === 'number'; } then match([1, 2], [pred(isNumber), pred(isNumber)], (x, y) => x + y ); should evaluate to 3.

• The class pattern instof(C, p₁, p₂, …, p_n), where C is a class In other words, C is a constructor function that is declared either directly or via the class syntactic sugar. , matches any value v for which both v instanceof C is true and C.prototype.deconstruct.call(v) matches the pattern [p₁, p₂, …, p_n]. On a successful match, a class pattern produces all of the bindings produced by p₁, p₂, …, p_n, in order.

  Every class should have a deconstruct method that takes no arguments and returns an array of values which constitute the “public view” of an instance of the class. The default implementation of this method, in “class” Object, should return the empty array — it is your responsibility to define this method. Other classes may override deconstruct. For instance, the deconstruct method of Cons in our example is defined as follows: Cons.prototype.deconstruct = function() { return [this.head, this.tail]; }; In other words, it returns an array containing the head and tail of the receiver. This allows the zip method to recursively pattern match on the structure of a list.

  Internal DSLs often define special APIs as hooks into the host language. Here, the deconstruct method gives the implementer of a class control over how instances are exposed when they’re used in pattern matching. Note that this view of the object does not have to correspond to its representation. For instance, the author of a Point class may choose to represent points with x and y properties, but deconstruct each point as a pair of (angle, radius) values.
• A limitation of the array patterns described above is that the programmer has to statically know the size of the array being matched. To make array patterns more flexible, we introduce the many( p ) pattern, which can only appear directly nested inside an array pattern. This pattern matches zero or more values that are matched by p and produces k bindings, where k is the number of bindings produced by matching against p. The i^th binding produced by many( p ) is an array of the i^th bindings produced from each of the matches against p. For example:

  match(['sum', 1, 2, 3, 4], ['sum', many(pred(isNumber))], nums => … )	evaluates to 10, assuming the body of the function to the left sums up the elements of the nums array.
  match([[1, 2], [3, 4]], [many([_,_])], (xs, ys) => [xs, ys] )	evaluates to [[1, 3], [2, 4]].
  match([1, 2, 3, 'and', 4], [many(_), 'and', _], (xs, x) => … )	throws a match failed exception because the many(_) will consume all of the elements of the array, and there will be no value to be matched by the 'and' pattern.
  match([1, 2, 3, 'and', 4], [many(pred(isNumber)), 'and', _], (xs, x) => … )	does match, with xs bound to [1,2,3] and x bound to 4.

  The somewhat unusual “column-oriented” array of bindings returned by a many pattern ensures that the number of bindings produced can be statically determined, independent of the number of values that end up matching the pattern at run time. For example, the pattern [many([_,_])] always generates two bindings.^{* *} Note that this is true even when the many pattern matches no values. Handling this case properly may require some special support in your implementation.
• Any other value — e.g., 42, 'foo', and undefined — can be used as a literal pattern, i.e., a pattern that matches any value that is equal (===) to it. Literal patterns don’t produce any bindings.

Keep in mind that match is just a regular JavaScript function, which means that its arguments will be evaluated before any pattern matching actually happens. This includes patterns like many(pred(isNumber)): they are plain old JavaScript expressions that will be evaluated to values before entering the match function.

Please do your work in a file called match.js. Each time you refresh this page, that file is loaded by our test harness to run the unit tests below. As in the previous assignments, you can add your own test cases by editing tests.js.

If you’re interested in pushing this project further, here are a few things you might like to try:

• Extend our DSL with support for JSON / object patterns. This is as much of a design exercise as it is an implementation exercise: you’ll have to figure out a nice way to expose this feature to the programmer (i.e., what should an object pattern look like?) and implement it.
• Design a better internal DSL for pattern matching in JavaScript.

• Gilad Bracha’s blog post on the advantages of internal DSLs over external DSLs.
• Martin Fowler’s book, Domain-Specific Languages, has a chapter about internal DSLs.