I Need Closure(s)

I received an email from JavaLobby, which had in it this article at EclipseZone, which talks about the plusses and minuses of adding features to Java. From the article:

Language guys love to tweak. I know, because I'm a language guy myself. I used to work on compilers, code generators, libraries, and debuggers. We were always adding new stuff, new commands, special keywords, etc. Did our users thank us for it? Maybe the one or two that wanted the new things, but the vast majority would just groan when a new release came out. What will this break now? Will I have to upgrade? Will I have to use somebody else's code that requires this new thing before I'm ready? Has it been ported to all the machines I need to run on? Boring, I know, but very practical and important issues.

Or... you can work in a language where if you want the one or two new things, you can just add them, and let the other guy that wants one or two other things added to the language add what he wants.

Or... I could just let Peter Siebel say it better:

DOLIST is similar to Perl's foreach or Python's for. Java added a similar kind of loop construct with the "enhanced" for loop in Java 1.5, as part of JSR-201. Notice what a difference macros make. A Lisp programmer who notices a common pattern in their code can write a macro to give themselves a source-level abstraction of that pattern. A Java programmer who notices the same pattern has to convince Sun that this particular abstraction is worth adding to the language. Then Sun has to publish a JSR and convene an industry-wide "expert group" to hash everything out. That process--according to Sun--takes an average of 18 months. After that, the compiler writers all have to go upgrade their compilers to support the new feature. And even once the Java programmer's favorite compiler supports the new version of Java, they probably still can't use the new feature until they're allowed to break source compatibility with older versions of Java. So an annoyance that Common Lisp programmers can resolve for themselves within five minutes plagues Java programmers for years.

I've been reading Ajax in Action, and have been reminded of the quote "Javascript is Lisp with a different syntax". It's usually used to stress the functional and closure features of Javascript, but there's another part that's also very close - attaching arbritrary properties to an object, including functions.

Compare

>var x = new Object()
>x.one = 1
1
>x.two = 2
2
>x.doubler = function(n) { return n * 2; }
function (n) { return n * 2; }
>x.two
2
>x.doubler(3)
6

with

CL-USER> (setf (get 'x 'one) 1)
1
CL-USER> (setf (get 'x 'two) 2)
2
CL-USER> (setf (get 'x 'doubler) #'(lambda (x) (* x 2)))
#<CLOSURE :LAMBDA (X) (* X 2)>
CL-USER> (get 'x 'two)
2
CL-USER> (funcall (get 'x 'doubler) 3)
6

In old Lisp textbooks I've seen this referred to as "data driven programming", used before anyone was talking about object-oriented programming. Now, no one would do OO this way in Lisp, but the quote didn't say "Javascript is Common Lisp with a different syntax".

I guess I'm having trouble with the correct incantations into Google. I'm trying to find information on natural language processing, preferably in Lisp but I'll look at anything, specifically towards taking in text and summarizing it.

I'm thinking of doing an RSS reader where long-winded feeds can be automatically summarized down to "abstract" form, and including a link back to the original article that the user can decide to read or just move on to the next article.

Any suggestions for starting points would be appreciated.

Just your run-of-the-mill Google Maps page, except for a couple of things; the server part is in Portable AllegroServe (no big deal), and the addresses came out of my Mac's Address Book via OpenMCL (a bigger deal).
I got interested in this after hearing an O'Reilly "Distributing the Future" podcast where someone mentioned that not everyone will want all their information on the web and there will be applications where part of the data is on the web and part is kept in the user's local storage.
The basic understanding of the Mac's AddressBook library came from this Mac Dev Center article, and help from Gary Byers got OpenMCL loading and searching the Address Book in OpenMCL. The rest is basic Portable AllegroServe.
The geocoder I'm using is Ontok, which has a REST api that takes up to 10 addresses at one time and returns CSVs that start with latitute and longitude co-ordinates.
Wil Shipley mentions that instead of using a database for storing customer orders he keeps them in XML files and uses Spotlight for searching. Something similar could be done with Address Book, just keep addresses in the built-in library instead of a database.
Code is here if you'd like to see.