Vladimir Sedach wrote:
PS is a translator from Common Lisp to JavaScript. The project stopped being an s-expression syntax for JS quite a while ago.
That, for me atleast, is great news. I had been wondering for sometime which direction Parenscript was headed in, and have had a CL->JS compiler high on my wishlist.
Do you plan to make it a complete ANSI CL to JS compiler? (Complete being whatever's allowed within the limits of the browser's security model e.g. file and socket operations might not work)
Does PS aim to become for CL like gwt is for Java? e.g. generating JS which works correctly across all the major browsers.
These are a few questions I have had for sometime -- I would really like to see something akin to gwt for CL.
Chaitanya
What if there were a special form to explicitly allow a Lisp symbol through unmodified? This would be a bit different than the current |:foo| syntax (the :-escape applies to whatever portion of the split symbol it prefixes e.g. |:foo.Bar.:baaZ| -> foo.bar.baaZ).
This isn't the issue with foo.bar syntax. The problem is that putting foo.bar in Parenscript (as opposed to outside the PS compiler) fails in the presence of symbol macros for either foo or bar. Even ignoring other possible undesirable consequences, this makes it a big pain to implement 'let' with real lexical scoping efficiently or readably, and makes code inspection by conventional tools impossible. The whole issue is centered around symbol identity and the abuse of symbol names.
Prefix syntax makes method calling a bit awkward and (.method ...) syntax makes method calls a bit more CLOSish in appearance. I am neutral on its value, but since parenscript has supported this for years and a lot of code is relying on it the cost of removing it is high.
The dot syntax is a design mistake that makes what should be trivial code transformation hard. This has consequences for both the PS compiler (keeping it would make it more complicated than it needs to be) and just as importantly as for the code being compiled. If someone wants to upgrade their project to use the latest version of Parenscript, I think it's ok to ask them to fix what are essentially bugs in their code. The only regrettable thing is that these bugs were encouraged by previous versions of Parenscript as desirable programming style.
Vladimir
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel