Here is one that prefers that parenscript is kept much as it is, a simple sexp syntax form of javascript without lisp features. My ideal parenscript has these features: * A simple syntax. You can immediately know what the generated javascript code looks like. You can code without having to look at the generated code to trust that it is correct.

<br>* Complete and stable syntax, you can do everything that javascript does.<br>* Easy to integrate with javascript code and libraries.<br>* Well tested, supported by automatic tests of all features. This makes

it easy to update the internal workings witout breaking user code. That

is the reason I made the testcode that syncs with the documentation, I

don't know how many use it though... <br>* Decent performance. Thanks Attila for the latest speedup!<br>I am very happy with parenscript as it is, as a high quality low level javascript translator close to my ideal.<br>

<br>But I can agree that sometimes a higher level language would be nice, and I have also dreamt of all the features mentioned. I am willing to hack on a new language that is more high level, but then I suggest we have two layers:

Parenscript as it is now (defined by my feature list above and the current syntax) as the low level language, call it parenscript-one. A new high level language (parenscript two) that compiles to parenscript one. But I suggest a clear division between the layers.

Not everyone may want to use parenscript two for numerous reasons, but they can use and contribute to parenscript one. And some ideas by parenscript two people goes into parenscript one (such as compacting whitespace in the generated javascript).  In fact, even Vladimirs idea to generate lisp code that generates javascript instead of direct strings might go into parenscript one, anything that doesn't change the syntax of the language.

Lispers are a scarce resource and it is good if we can make all contribute to the same project. I think the current definition of parenscript as a direct sexp syntax of javascript is the lowest common denominator of everyones goals. But once you start to make something higher level peoples taste and needs will be more different. If you are tied to one of the big javascript frameworks you might be forced to use their implementation of objects. Or you might want to implement CLOS in javascript, as Red Daly does. Or have yet another homemade object implementation, as I currently have. Some want continuations, some don't care. We should do our best to make it possible to pick the features every need. But everyone needs a basic sexp syntax of javascript to build upon.

<br><br>Summary: Thumb up for a nice high level language, but keep a low level language as well.<br><br>/Henrik Hjelte<br>