Re: Lisp as a procedural language?
От | John DeSoi |
---|---|
Тема | Re: Lisp as a procedural language? |
Дата | |
Msg-id | AFCC1285-AB94-4675-B642-7F49CCBA6A80@pgedit.com обсуждение исходный текст |
Ответ на | Re: Lisp as a procedural language? ("Douglas McNaught" <doug@mcnaught.org>) |
Ответы |
Re: Lisp as a procedural language?
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: