Re: Lisp as a procedural language?

From: "Douglas McNaught" <doug(at)mcnaught(dot)org>
To: znmeb(at)cesmail(dot)net
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Lisp as a procedural language?
Date: 2008-10-19 17:27:23
Message-ID: 5ded07e00810191027w733b7b42n5c6b642ec733b99e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message M. Edward (Ed) Borasky 2008-10-19 18:50:03 Re: Lisp as a procedural language?
Previous Message Nathan Boley 2008-10-19 17:09:47 Re: Cross-column statistics revisited