Hi John,
I realise that pretty much all of these are just syntactic sugar, but I wanted to ask whether anyone other than me thinks it would be nice if Parenscript knew about these modern niceties and could be directed to generate them, and what the general roadmap (if any) is for Parenscript, before I start looking at what's involved.
Adding support for newer ECMAScript features in Parenscript output is part of the plan. There is a variable *JS-TARGET-VERSION* that controls the ECMAScript version the output will target. Peter Stirling has already started work towards ECMAScript 2015: https://github.com/vsedach/Parenscript/pull/39
The general road-map I have in mind is, first, to release Parenscript 2.7. I plan to make 2.7 the last 2.x Parenscript release.
After the release, the Parenscript code will become part of Parenscript 3, which will have some incompatible changes: removal of deprecated macros and special operators, and different system and package names (to prevent conflicts between Parenscript 2.x and 3, and to no longer define short two and four letter package names, which conflict with people's package nicknames in their systems and the REPL).
I also have a pile of ideas for improving the internals of the Parenscript compiler, and improvements in the efficiency and correctness (with respect to Common Lisp semantics) of the generated Parenscript code, that are non-breaking changes.
The most significant change for Parenscript 3 will be the license: Parenscript 3 will incorporate the 3 clause BSD licensed Parenscript 2 code into a copyleft (GPL version 3 or later) project. There are a lot of reasons for this that I can go into in more detail, if anyone is interested. The short explanation is that my experiences in the past six years have very strongly convinced me that working on non-copyleft Free Software is against my own (and the general public's) interests. I have decided to re-license Free Software projects that I created or maintain under the GPL.
Vladimir