[avibryant]

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.

[gruseom]

Yeah, perhaps I'll write something that once we have a bit more experience with server-side PS.

Interesting what you say about foo.bar; PS originally did that, and I was one of the people who lobbied against it. It does make getting started a little easier, but interferes with macros down the road. For example, if you want to do anything like transforming foo.bar to foox.barx, you end up having to parse the symbols to split them, which seems wrong. Since Lisp-style metaprogramming is pretty much Parenscript's raison d'être (well, that and interoperability with CL for the crazy few who care), it seems foolish to do anything to compromise it.

[avibryant]

Why not consider it a reader macro, and translate it to (@ foo bar) or whatever is appropriate, before applying macro expansion?

[sedachv]

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.

[gruseom]

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