Re: Unlearning Pattern Matching
- From: alflisppython@xxxxxxxx
- Date: Sat, 30 Jun 2007 03:38:36 -0700
On 30 jun, 10:14, Jon Harrop <j...@xxxxxxxxxxxxxxxxx> wrote:
André Thieme wrote:
Jon Harrop schrieb:
Dan Bensen wrote:
This ML-style pattern matcher takes just a few hours to write...
A good educational exercise but Greenspun.
Why is it Greenspun?
He is reimplementing half of a modern FPL (the pattern matcher). The
implementation is ad-hoc (not even a feature list) and if it took a few
hours then he most likely didn't read any of the research that has been
done in this area. There is no specification. The implementation doesn't
affect the compiler's optimizer, so it will be comparatively slow.
So we have:
ad-hoc
informally-specified
bug-ridden
slow
reimplementation of half of OCaml/SML/Haskell/F#/Scala/.
The pattern matchers in these languages are well-specified, mature and fast.
So lashing together something that looks similar is classic Greenspun. That
doesn't stop it from being a good educational exercise, of course, but the
proof is in the pudding so Dan might like to benchmark his implementation
against some of the major players.
--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journalhttp://www.ffconsultancy.com/products/ocaml_journal/?usenet
The book "Lisp in small pieces" LISP
of C.Queinnec give some good examples of pattern-matching and
filtering and
construct an interface for a natural robot language.
The examples are in lisp but not common lisp.
http://www-spi.lip6.fr/~queinnec/WWW/LiSP.html
.
- References:
- Unlearning Pattern Matching
- From: Dan Bensen
- Re: Unlearning Pattern Matching
- From: Jon Harrop
- Re: Unlearning Pattern Matching
- From: André Thieme
- Re: Unlearning Pattern Matching
- From: Jon Harrop
- Unlearning Pattern Matching
- Prev by Date: Re: Unlearning Pattern Matching
- Next by Date: calling compiled lambda forms
- Previous by thread: Re: Unlearning Pattern Matching
- Next by thread: incf and hash-tables
- Index(es):
Relevant Pages
|
Loading