Re: [HACKERS] Lisp as a procedural language?

[John DeSoi]

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.





--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Lisp as a procedural language?

[Joshua Tolley]

On Mon, Oct 20, 2008 at 12:56 PM, John DeSoi <[EMAIL PROTECTED]> 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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Lisp as a procedural language?

[John DeSoi]

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.





--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Lisp as a procedural language?

[M. Edward (Ed) Borasky]

On Sun, 2008-10-19 at 09:24 +0300, Volkan YAZICI wrote:
> "M. Edward (Ed) Borasky" <[EMAIL PROTECTED]> 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



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Lisp as a procedural language?

[Douglas McNaught]

2008/10/18 M. Edward (Ed) Borasky <[EMAIL PROTECTED]>:

> 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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Lisp as a procedural language?

[Volkan YAZICI]

"M. Edward (Ed) Borasky" <[EMAIL PROTECTED]> 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/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Lisp as a procedural language?

[Tom Lane]

"M. Edward (Ed) Borasky" <[EMAIL PROTECTED]> 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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Lisp as a procedural language?

[Andrew Dunstan]

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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Lisp as a procedural language?

[M. Edward (Ed) Borasky]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Lisp as a procedural language?

[Nikolas Everett]

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 <[EMAIL PROTECTED]>

> 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
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

[HACKERS] Lisp as a procedural language?

[M. Edward (Ed) Borasky]

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



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers