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
