Introducing lisp.js: a Lisp for node.js

http://lisp-js.posterous.com/lispjs-a-lisp-for-nodejs-0

by devijvers • 16 years ago

64 30 16 years ago

lisp-js.posterous.com

I like this! I just put a reminder on my calendar for 3 months from now to more-fully check out the project.

maxtilford2• 16 years ago

Awesome. I've got it up and running. I've been looking for a solution for the client/server distinction for a while. How much have you thought about the implementation of that?

devijvers6• 16 years ago

Good to hear! What do have in mind when you say "client/server distinction"?

maxtilford2• 16 years ago

Mainly, I'm tired of using $.getJson, and I liked your on-server macro. Also, how is the server going to watch references on the server and vice-versa?

gruseom6• 16 years ago

While it's always great to see experimentation in the Lisp realm, I'm unclear as to what "a Lisp for node.js" will do that the mature Lisp-on-top-of-JS (Parenscript) doesn't already do.

devijvers6• 16 years ago

Thanks for the reference to Parenscript which I'm unfamiliar with. The main point of lisp.js is to benefit from node.js' event-loop/non-blocking-i/o environment. node.js will be able to handle far greater loads than web servers that use blocking I/O. I'm not sure whether or not the Common Lisp web server exclusively uses non-blocking I/O on the account that I'm not familiar with that web server. I'm erring on the side of blocking I/O in which case node.js/lisp.js would run circles around that web server.

gruseom6• 16 years ago

Using Parenscript with Node.js would presumably mean throwing out any Common Lisp web server and relying on Node to do the I/O. Otherwise, as you point out, you don't get much benefit from Node. In such a setup, Node (or Node behind a reverse proxy) would be the web server, Parenscript code compiled to JS would do whatever was needed in Node, and if you wanted application logic in a Lisp at runtime, you could call it however Node does IPC.

The value that Parenscript adds here is the same as for programs that run in a web browser: you write your JS in a Lispy way at a higher level of abstraction, mostly because you get the full power of Lisp macros. There are other wins too, but that's the big one. The runtime environment, though, is entirely JS, because PS is a compiler that targets JS.

So I still don't see a difference in intent here between what PS is good for and what you're doing. I don't want to discourage you at all. Just curious about the differentiator.

jashkenas• 16 years ago

There's also already a Lisp-on-Node project called Sibilant. Jake's got a neat live-compile-in-the-browser demo up here:

http://sibilantjs.info

And the source is available here (and as an NPM package):

http://github.com/jbr/sibilant

gruseom6• 16 years ago

I went through the demo and have the same question about this: why greenspun Parenscript in this manner? It does all these things, and zillions more, in a nice way. The only reason I can think of is fun, which is perfectly legitimate. Or maybe people don't want to run Common Lisp even to compile their code?

tlrobinson• 16 years ago

So you mean "Lisp for JavaScript"? Why limit it to node.js?

devijvers6• 16 years ago

It might one day become a general lisp for javascript but for now the concurrency-free server-side environment of node.js is assumed.

DTrejo2• 16 years ago

lisp.js will be a lisp-2 (like Common Lisp and unlike Clojure and Scheme)

Can you talk more about this decision?

devijvers6• 16 years ago

Macros are important, that's why I seeking guidance in Let Over Lambda. The most suitable lisps for writing macros are lisp-2, hence the preference for a lisp-2 dual namespace.

pwpwp• 16 years ago

Lisp-2's have less potential for trouble with unhygienic macros, but they still have it. Hygienic macro systems work with Lisp-1 as well as with Lisp-2.

Apropos, I've written a Lisp->JS compiler a while ago; you might find some of the code useful: http://github.com/manuel/cyberlisp/

sreque• 16 years ago

I think the Scheme and Racket communities would take issue with your claim that lisp-2 languages are more suitable for writing macros than their respective languages :)

Introducing lisp.js: a Lisp for node.js

Related Stories