Basically, the server "knows" (as in can know) the references that exist on the client and vice versa. When a watched reference changes value on the client an HTTP request/response is sent over the wire. The request carries the old and new value, the response is basically redundant but since it's HTTP it needs to be there. Hence, the response might carry new forms to be executed on the client.

The client watching references on the server is obviously more tricky. node.js already supports keep-alive by default. There probably needs to be some kind of chuncked reply mechanism that allows the server to send changes without the client having to send polling requests. Obviously, if the reference is not going to change frequently it might be cheaper to just poll every once in a while.

on-server reminds me of Hop. Take a look at http://hop.inria.fr/, maybe http://hop.inria.fr/usr/local/lib/hop/2.1.1/weblets/home/art... in particular.

In regards to hygienic macros and Hoyte's Let Over Lambda, the type of variable capture hygiene is designed to prevent is actually used as a programming technique in the book; Hoyte calls it free variable injection.

Lisp-1 vs Lisp-2 actually has very little to do with macros. Most of the inconvenience comes when writing functions - things like having to name list parameters "lst." The way Common Lisp gets around the variable capture problem is to forbid the rebinding of special forms, functions, and macros defined in the standard.* This is an ugly hack that forces early binding, and obviously does nothing to prevent capture of user-defined functions.

The Scheme wiki has a good article on hygiene: http://community.schemewiki.org/?hygiene-versus-gensym

* - This wasn't done for the sake of macros. The rationale behind the decision as I heard it is to prevent the hypothetical scenario of some standard function like cdr that's called inside the garbage collector or allocator from being rebound to something that tries to allocate memory and crashes the gc or sends the allocator into an infinite loop. I don't really buy it; it's easy enough to prevent these types of scenarios.

You might also check out the Racket->JS compiler:

http://planet.plt-scheme.org/display.ss?package=moby.plt&...

I used it just last year — the developer, dyoo, is super responsive.

I'm sure he'd be happy to talk shop with you: http://github.com/dyoo/moby-scheme

I've scanned the Parenscript docs and it doesn't seem immediately obvious how to combine node.js and Parenscript without having to include Common Lisp. Also, there's a number of things on my wish list that compelled me to write my own lisp implementation (there are other JavaScript lisp implementations):

* only requirement is node.js and the lisp source distribution, no other dependencies. * ability to debug lisp code from the browser. * immutable data structures.

I feel I can implement a lisp that can run the examples in <i>Let Over Lambda</i> in a couple of weeks. The lisp won't be as stable as Parenscript but that's ok. Only at that point can the real work start of building the web framework that is lisp.js. I think the most important bit for me is to have a base that I can modify as the needs arise. I'm already trying to include as many lisp concepts in the test source as I can find to make sure lisp.js is a general purpose lisp. In that respect I'm setting several goals: get lisp-in-lisp working, get Let Over Lambda examples working, ... any other useful lisp constructs that I come across. That's a journey I can only make if I do my own lisp implementation.

    (defvar *http* (require "http"))
    (chain *http*
           (create-server (lambda (req res)
                            ((@ res write-head) 200
                                                (create "Content-Type"
                                                        "text/plain"))
                            ((@ res end) "Hello, World!\n")))
           (listen 8124 "127.0.0.1"))
    ((@ console log) "Server running at http://127.0.0.1:8124/")

As the author of sibilant: A) it was/is fun B) I don't want to be dependent on another language — sibilant is entirely self-hosting, like coffeescript. Additionally, I don't want to be constrained to pure lisp. I'd like for sibilant to evolve into a language that incorporates the best elements of lisp and javascript. Since sibilant is written in sibilant, there's no dependence on pure lisp and the language can evolve in its own direction.

There's something satisfyingly elegant about using an interpreted language to interpret another language - macros can actually modify the compiler at compile-time, from within the language. I hope to make more use of this possibility in the future, as it's currently only used for macros.

Some reasons I can think of: it's definitely an advantage to be able to compile the code on the client-side, which sibilant should be able to do; I don't know if Parenscript can bootstrap itself the same way. Some people, like me, prefer lisp-1 to lisp-2. Being less like Common Lisp and more like Javascript can be an advantage; sibilant seems to support foo.bar notation for accessing JS properties, which I think is the right choice in this context (I would also like to see JS/JSON literal syntax supported).

All of the docs on Parenscript seem to assume you're using it to render bits of JS and HTML from a Common Lisp server. It would be useful if there were a tutorial that showed how to use Parenscript for this use case, simply to compile lisp-like code into standalone JS files for use with whatever arbitrary backend.

I don't know this particular author's intentions, but I can definitely see a reason to create a new Lisp over Javascript: I like functional programming, so I'd like something Schemey or Clojurey rather than CLish.

I considered doing that, but it pretty much means rewriting the reader because it changes the grammar so much. Not that it's not possible, I just don't trust myself not to make it full of bugs.

Seems possible. You'd have to make . be a macro character, which would ruin dotted lists, but Parenscript doesn't have those anyway.