"While the dot operator's base form should be a prefixed s-expression like all the others, it may be awkward to use in practice" The solution isn't special syn

"While the dot operator's base form should be a prefixed s-expression like all the others, it may be awkward to use in practice" The solution isn't special syntax, it's macros. Check out Parenscript's chain: http://common-lisp.net/project/parenscript/reference.html#chain http://common-lisp.net/project/parenscript/reference.html#ch... "For blocks we use a wrapper function rather than the curly brace block so that lexical scoping for variables can be ensured." In most cases you can generate more efficient code by doing rudimentary control flow analysis. Look at how RETURN-FROM is implemented in the current Parenscript repository version. Also, speaking of lexical scoping don't forget that in JS loop variables only get a single binding. Scheme2JS uses a neat trick with with to implement the proper (per-iteration) binding (see this paper: http://www-sop.inria.fr/indes/scheme2js/files/icfp2006.pdf http://www-sop.inria.fr/indes/scheme2js/files/icfp2006.pdf). It's the only useful use of with I've ever encountered. "The ternary operator" Don't. The #1 goal of any new Lisp to JS translator should be to eliminate the statement/expression dichotomy. "We could build a simple unhygienic macro system using the traditional quote ('), quasiquote (`), unquote (,) and unquote-splicing (,@) operators, as well as rest parameters (&)." Take it one step further and make quasiquoting be able to build arrays at runtime. This is something that Daniel Gackle (gruseom) suggested for Parenscript and I need to implement. I actually want to take it a step further still and have a matching system like fare-matcher (http://www.cliki.net/fare-matcher http://www.cliki.net/fare-matcher) based around quasi-quoting. If you write all your code this way, you can go a long way towards eliminating dependence on the specific data structures you use for representing s-expressions. Right now I suspect you can go all the way, and that it's a viable strategy for making Parenscript self-hosting without adding runtime support for car/cdr to JavaScript. Speaking of runtime libraries, I think it's an implicit assumption you made already, but if you want to be like Coffeescript or Parenscript, you obviously need to avoid those.