Hello,
Monstara monstara@gmail.com writes:
there could be a discussion whether to "modernize" parenscript, since ECMAScript moves faster than is customary in Lisp. I have started studying and playing with the parenscript code, and I am interested in adding some newer ECMA features.
First off, let me say that I was unable to call (super) inside a constructor, the way paren6 works (since the prototype is explicitly set after the class function is declared). Therefore I feel it would be better if the compiler itself supports js classes. Once I get better acquainted with the compiler, would there be an interest in other ECMA features being added? I don't know, maybe async? Or something else. I'm open to suggestions.
There are a few things to consider. With ES5 it was straightforward to ensure "Parenscript code can run almost identically on both the browser (as JavaScript) and server (as Common Lisp)." ES6 and especially ES7 make this a dubious goal, because of promises and async. Would you really want to write JS-style async code in Common Lisp? Would you really want to write JS-style async code at all?
A few big projects used Parenscript for server-side Node.js deployment long before ES6, so obviously some people think it's a good idea.
In terms of backward compatibility, it would probably mean forking the project - you would want to introduce package names like parenscript7, parenscript8, whatever new ECMA iteration is referred to; instead of using the *js-target-version* special variable. Dropping other stuff like the short name "PS" package (that was such a bad idea in hindsight) and having people use package-local nicknames; removing deprecated keywords such as "with"; other backwards-incompatible changes should also be a priority.
-- Vladimir Sedach