Re: Lisp as a procedural language?

2008/10/18 M. Edward (Ed) Borasky <znmeb(at)cesmail(dot)net>:

> GCL (and Clisp) are both reasonable implementations of Common Lisp.
> However, they are both GPL, which I think is an issue for PostgreSQL
> community members. CMUCL development more or less stalled out, and many
> of the heavyweights moved to Steel Bank Common Lisp (SBCL). It's kind of
> a joke -- Carnegie => Steel, Mellon => Bank, so Carnegie Mellon
> (University) Common Lisp => Steel Bank Common Lisp. :)
>
> In any event, SBCL is MIT-licensed, which is free of some of the more
> "annoying" GPL restrictions. BTW, I checked on XLispStat and it seems to
> be frozen in time -- most of the people who used to use XLispStat
> (including me) have moved on to R (which is GPL, unfortunately).

I'm not an expert, but from lurking on the SBCL mailing list for a
while, I can say the following:

SBCL is a big and very sophisticated program. It's designed to be a
self-contained Lisp system and has (AFAIK) no concessions to
"embeddability". It uses threads internally, and plays games with the
memory map to make GC more efficient. Only a small part of it is
written in C, and the rest is Lisp compiled directly to binary. It
would almost certainly be a heroic project to make it coexist with a
PostgreSQL backend process--like Java, but much worse.

It's not likely that any of the "serious" Common Lisp systems would be
easily embedded in Postgres.

-Doug