Обсуждение: Lisp as a procedural language?
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. -- 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
<div dir="ltr">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.<br /><br/><div class="gmail_quote">2008/10/18 M. Edward (Ed) Borasky <span dir="ltr"><<a href="mailto:znmeb@cesmail.net">znmeb@cesmail.net</a>></span><br/><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Someone at the PostgreSQLWest conference last weekend expressed an<br /> interest in a Lisp procedural language. The only two Lisp environments<br/> I've found so far that aren't GPL are Steel Bank Common Lisp (MIT,<br /><a href="http://sbcl.sourceforge.net"target="_blank">http://sbcl.sourceforge.net</a>) and XLispStat (BSD,<br /><a href="http://www.stat.uiowa.edu/%7Eluke/xls/xlsinfo/xlsinfo.html" target="_blank">http://www.stat.uiowa.edu/~luke/xls/xlsinfo/xlsinfo.html</a>).SBCL is a<br /> very active project, but I'mnot sure about XLispStat.<br /> --<br /> M. Edward (Ed) Borasky<br /><a href="http://ruby-perspectives.blogspot.com" target="_blank">ruby-perspectives.blogspot.com</a><br/><br /> "A mathematician is a machine for turning coffee into theorems."--<br /> Alfréd Rényi via Paul Erdős<br /><font color="#888888"><br /><br /><br /> --<br /> Sent via pgsql-hackersmailing list (<a href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br /> To makechanges to your subscription:<br /><a href="http://www.postgresql.org/mailpref/pgsql-hackers" target="_blank">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/></font></blockquote></div><br /></div>
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]? 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.