Hacker News new | past | comments | ask | show | jobs | submit login
Clojure Pattern Matching Lib: literal, seq, map and other patterns (groups.google.com)
72 points by gtani on Aug 9, 2011 | hide | past | favorite | 10 comments



One of the main developers here. Couple of points that aren't mentioned in the thread or aren't obvious w/o reading the whole thing:

* This is yet another example of how powerful macros are. All the features described are implemented in ~700 lines of code and a single macro.

* The pattern matching library is meant to be user extensible - you'll be able add your own patterns / syntax. Users simply need to bring their data types to whatever protocol is required by your new pattern. I think this going to be crazy powerful. For example - very fast pattern matching on primitive arrays / buffers.

* This is the groundwork for bringing high performance predicate dispatch to Clojure. This is under explored territory for dynamic languages.


* This is the groundwork for bringing high performance predicate dispatch to Clojure. This is under explored territory for dynamic languages.

I really like the way how pattern matching (in Haskell, etc) is transformed into a bunch of case expressions, which can then be compiled into code where each argument is evaluated only once and each "then" expression is compiled only once (no duplicates).

However, to my best knowledge, it requires some static type information to make the compiling transformation possible. E.g. the Haskell compiler knows that a Maybe Bool can have only three possible values: Just True, Just False or Nothing.

How do you do this in Clojure with dynamic typing? This really intrigues me and you're really pushing the boundaries of dynamic languages and compiling here a little bit. Very interesting indeed!

* For the uninitiated: you can find good description of compiling pattern matching in Simon Peyton Jones's book here: http://research.microsoft.com/en-us/um/people/simonpj/papers...


This library will produce a decision tree where each argument is only tested once - no backtracking. How is a bit too much to explain here. I recommend the Maranget paper Compiling Pattern Matching to Good Decision Trees on which this work is based.


Thank you, this looks really awesome.

I'm pretty new to Clojure, but one of the things that I'm starting to pick up on is the ridiculous speed with which the language can evolve. It seems that in non-Lisp languages, features like this would have to start as compiler extensions and would only move into the mainstream via the molasses-slow process of maybe being included in the mainline compiler. With Clojure, the language can iterate as fast as any library. Pretty exciting.


Just add a Prolog interpreter, and then you will have the most powerful pattern matching avaiable: unification[1]

[1] http://en.wikipedia.org/wiki/Unification_%28computer_science...


I already wrote a Prolog-like engine and it has unification based pattern matching - https://github.com/clojure/core.logic

Unification based pattern matching is fantastic in its generality - not so much performance.


Writing a Prolog-style interpreter is one of the most fun computer science projects I've ever done. I wrote it at the uni as a project work for an AI course. I did it in Haskell, and my professor got really interested in the language after evaluating my work.

So here's my little logic programming interpreter: https://github.com/rikusalminen/slolog


Awesome, one of the things I was really missing coming from Erlang.


I saw guards mentions in the "notes" but no evidence in the TODO. Does guarded pattern matching work with your compilation strategy?


I have some rough thoughts on how to implement guards, nothing concrete, but I don't see any obstacles to integration with our compilation strategy.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: