Just relaying an email from Fare Rideau, the guy who wrote fare-matcher.
What with all the hoopla recently over pattern matching, it seems like
an interesting subject to study.
> Dear Dan,
>
> sorry for the slow answer - I'm in vacations and not very
> net-connected.
>
> If you have small patches to fare-matcher, you can start a fork and/or
> send them and I may apply them.
>
> Now if you're interested in sizeable hacking, I don't currently have
> plans for fare-matcher, but I have ideas.
>
> 1- you should take a look at arnesi's pattern-matcher, too, and to
> what the plt guys have, too -- oh, and screamer.
> 2- of course, you should be familiar with ML, prolog, Mercury.
> 3- I like the general look&feel of fare-matcher best over the other
> ones. It is totally natural to reuse the symbols of the CL package (or
> whichever user-extension is used) and associate to them a
> deconstructing aspect just like they have a constructing aspect. The
> matcher is a natural subset of a more general logic programming
> language (as in Screamer)
> 4- the internals of fare-matcher are limited and primitive, and would
> be better rewritten. I believe arnesi already has better internals,
> though I find its interface with :keywords most distasteful.
> 5- with a better factoring, i.e. using higher-order abstract syntax
> (HOAS), internals ought to both be much cleaner and much more
> versatile -- i.e. the same description of how to match a construct
> could be used to generate code with or without backtracking, etc.
> 6- just as in ML, the matching system should go hand in hand with the
> type-definition system, to define structures, etc., that can be
> matched as well as constructed. The CL typesystem cannot be salvaged
> for that, though -- a whole new thing (type, structs) has to be
> implemented on top of CL and below the matcher -- can be a worthy
> thing, tho, especially considering the existing efforts for
> algorithmic libraries concerning pure functional and other
> data-structures.
> 7- it might be possible to write things in a clean way with
> higher-order functions, and optimize a whole lot of things with
> compiler-macros
> 8- when you don't allow backtracking, then the continuation closures
> that you pass to the higher-order functions have dynamic-extent, and
> that's a huge source of optimization, especially since it allows for
> closure-conversion and avoiding the slow multiplication of heap frames
> for the matching, grouping them all in a one stack frame instead. A
> good ML compiler will do that implicitly for you. The Lisp spec
> precludes this optimization, and so will rely on your matching macros
> and/or compiler-macros to do that for it -- if you care about
> performance.
>
> PS: feel free to share this mail around, including on c.l.l if there
> is still interest in this topic.
>
> PPS: I'm willing to give advice to someone who'd undertake the project
> of extending Lisp this way, and even give coaching if the person lives
> near Boston.
>
> [ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics |
> http://fare.tunes.org ]
> There is no excuse for a programming language without clean formal
> semantics.
> For even if your language is not designed for formal reasoning by
> computers,
> there will still be humans who'll have to reason about programs.
--
Dan
www.prairienet.org/~dsb/