Classes, updating parenscript

[Vladimir Sedach]

Hello,

Monstara <monstara at 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