I checked around for a Lisp version of list comprehensions, and sure enough, back in 1999 I had developed one. Here is the Lisp source for one implementation of list comprehensions. This version does not make use of pattern matching, and so does not have the concept of refutable patterns either.
Setting up a speed competition between Lisp and NML, we wrote a version of PyTriple in both languages based on list comprehensions, just like that shown in the previous posting.
Here is the result of running PyTriple on all integers from 1 to 400:
Lisp compiled 1.5 sec
NML 15
Lisp interpreted 58
So Lisp (compiled to native code) is 10 times faster than NML in this case.
(I’m using LispWorks Lisp for Macintosh, 32-bit version 5.01, on a 2 GHz iMac Intel Core-Duo. NML also runs on this same machine.)
Oh well... this isn’t the core strength area for NML, but at least we can write such expressions and execute them. The real advantage for NML shows up in massive vectorized calculations, as with data reduction and numeric modeling. But Lisp can give a real run for the money... It just isn’t as convenient, syntax-wise...
------------------------
There is one glaring problem with both the NML and the Lisp implementations of List Comprehensions...
Both of them utilize the “foldr” operator, which works its way from the end of the list forward. But many of these kinds of computations expect to work on potentially unlimited streams of data, and there simply isn’t a “right-end” of such a list. That’s where the laziness of Haskell can out-gun us -- unless we rephrase all of these efforts using our lazy streams...
Sunday, February 4, 2007
