[dgreensp]

Yes, critically speaking, the author seemed on track to implementing an extensible pattern matching system based on macros, before stopping to end with the point that it wasn't the obvious, idiomatic, built-in thing to do.

And in this system, patterns are expressions. So "everything is an expression" isn't exactly wrong in this case.

In Scala, you are given full control over both how a name "applies" (i.e. what Foo(...) does when called as a sort of constructor or factory method) and how it matches, in the form of an "unapply" static method that you implement. It seems like a "match" macro in a LISP could desugar a pattern into a program that matches that pattern, the same way the Scala compiler generates code that calls "unapply".

[rntz]

Author here. I have created a language, called moxy (https://www.github.com/rntz/moxy), which supports not just extensible pattern-matching but defining extensible extensions in general (of which pattern matching is one example, LINQ might be another, and so on and so forth). However, it wasn't a lisp, because I also wanted to see whether I could support syntactic extensibility in a non-lisp language.

The really important point, that moxy explored and that I think I didn't make clear in the article, is that patterns are just one example of where you want extensibility of a non-expression syntax class. Really you want to be able to define your own syntax classes and be able to extend them!

I only mentioned moxy in a footnote in the article because it's "research-quality" at the moment - it's not well documented and I'm still having second thoughts about its design. I've moved on to other thing and am busy with work, so I don't imagine I'll be working on it in the immediate future.