Lisp as a procedural language?

From what I remember with tinkering with Lisp a while back, SBCL and CMUCL
are the big free implementations. I remember something about GCL being
non-standard. Either of those should make lisp hackers happy.

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

On Sat, 2008-10-18 at 20:43 -0400, Nikolas Everett wrote:

From what I remember with tinkering with Lisp a while back, SBCL and
CMUCL are the big free implementations. I remember something about
GCL being non-standard. Either of those should make lisp hackers
happy.

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).
--
M. Edward (Ed) Borasky
ruby-perspectives.blogspot.com

"A mathematician is a machine for turning coffee into theorems." --
Alfr�d R�nyi via Paul Erd�s

M. Edward (Ed) Borasky wrote:

On Sat, 2008-10-18 at 20:43 -0400, Nikolas Everett wrote:

From what I remember with tinkering with Lisp a while back, SBCL and
CMUCL are the big free implementations. I remember something about
GCL being non-standard. Either of those should make lisp hackers
happy.

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).

We're almost certain not to be including a Lisp PL in the core
distribution, so the license shouldn't be an issue (c.f. PL/R)

cheers

andrew

"M. Edward (Ed) Borasky" <znmeb@cesmail.net> writes:

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.

Well, it would be an issue if we wanted to distribute PL/Lisp as part of
the core; but I kinda doubt that there would be enough demand to justify
that. As long as it's a separate project I don't see much wrong with
depending on a GPL Lisp implementation, if you find that that's the best
choice technically.

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. :)

Not that I've got anything against CMU software ;-)

regards, tom lane

"M. Edward (Ed) Borasky" <znmeb@cesmail.net> writes:

Someone at the PostgreSQL West conference last weekend expressed an
interest in a Lisp procedural language. The only two Lisp environments
I've found so far that aren't GPL are Steel Bank Common Lisp (MIT,
http://sbcl.sourceforge.net) and XLispStat (BSD,
http://www.stat.uiowa.edu/~luke/xls/xlsinfo/xlsinfo.html). SBCL is a
very active project, but I'm not sure about XLispStat.

You see PL/scheme[1]http://plscheme.projects.postgresql.org/?

Regards.

[1]: http://plscheme.projects.postgresql.org/

2008/10/18 M. Edward (Ed) Borasky <znmeb@cesmail.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

On Sun, 2008-10-19 at 09:24 +0300, Volkan YAZICI wrote:

"M. Edward (Ed) Borasky" <znmeb@cesmail.net> writes:

Someone at the PostgreSQL West conference last weekend expressed an
interest in a Lisp procedural language. The only two Lisp environments
I've found so far that aren't GPL are Steel Bank Common Lisp (MIT,
http://sbcl.sourceforge.net) and XLispStat (BSD,
http://www.stat.uiowa.edu/~luke/xls/xlsinfo/xlsinfo.html). SBCL is a
very active project, but I'm not sure about XLispStat.

You see PL/scheme[1]?

I don't remember who it was at the conference, but when I suggested
Scheme, he said that it already existed, and that (Common) Lisp was
really what was wanted.

Scheme is a much simpler beast. Both Scheme and Common Lisp are similar
in complexity at the core/"virtual machine"/interpreter/compiler level.
But once you load on all the libraries, object models (CLOS), etc.,
Common Lisp is much bigger.
--
M. Edward (Ed) Borasky
ruby-perspectives.blogspot.com

"A mathematician is a machine for turning coffee into theorems." --
Alfréd Rényi via Paul Erdős

On Oct 19, 2008, at 1:27 PM, Douglas McNaught wrote:

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.

Probably the ideal implementation would be ECL:

http://ecls.sourceforge.net/

It is designed to be a full Common Lisp implementation that can be
easily embedded in other environments.

It generates C source code so you could have the option of developing
with Lisp and then generating C language functions for additional
speed or source code security.

Not open source, but I've played around a bit with integrating
LispWorks to get Lisp a procedural language.

I'd like to see Lisp as a procedural language, but I'm not very
proficient with C. If anyone is interested in leading the way, I would
be happy to help.

John DeSoi, Ph.D.

On Mon, Oct 20, 2008 at 12:56 PM, John DeSoi <desoi@pgedit.com> wrote:

On Oct 19, 2008, at 1:27 PM, Douglas McNaught wrote:

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.

Probably the ideal implementation would be ECL:

http://ecls.sourceforge.net/

It is designed to be a full Common Lisp implementation that can be easily
embedded in other environments.

It generates C source code so you could have the option of developing with
Lisp and then generating C language functions for additional speed or source
code security.

Not open source, but I've played around a bit with integrating LispWorks to
get Lisp a procedural language.

I'd like to see Lisp as a procedural language, but I'm not very proficient
with C. If anyone is interested in leading the way, I would be happy to
help.

John DeSoi, Ph.D.

One of the Java-as-a-procedural-language options uses RMI to get the
server talking to a separate JVM, where the actual function processing
gets done. Could a PL/Lisp work similarly (and would it be anything
approaching a good idea...)?

- Josh / eggyknap

On Oct 20, 2008, at 3:00 PM, Joshua Tolley wrote:

One of the Java-as-a-procedural-language options uses RMI to get the
server talking to a separate JVM, where the actual function processing
gets done. Could a PL/Lisp work similarly (and would it be anything
approaching a good idea...)?

I think it could work, but it is hard to say how good an idea it would
be without being more familiar with the implementation details on what
it takes to create a complete procedural language.

There might be some useful ideas from SLIME (http://common-lisp.net/project/slime/
) which connects to many different Lisp implementations to provide a
Lisp IDE in Emacs.

BTW, this is Lisp's 50th birthday being celebrated today at OOPSLA.

http://www.lisp50.org/

John DeSoi, Ph.D.