<div dir="ltr">Thanks a lot for the response, Vladimir.<br><br>The goal of generating valid Javascript and Lisp from the same code is commendable. I could not pull it off :)<br>Definitely agree that the new project should be a fork.<br>While I would not strive for compatibility, I would like to know more about the use cases of generating lisp and js from the same code. Is it in the spirit of "isomorphic web frameworks?"<br><br>Right now I really need classes (for a fun side project), and have a basic implementation to translate them. It is far from ready to go public, but I use it.<br>In relation to this, I wonder how closely to follow the Javascript spec. Paren6 has some semantic checks that seem to follow it, e.g. "only a single constructor method is allowed," but PS also has its own semantics, which likely aim to preserve lispiness?<br><br>Async is not my goal, but I won't dismiss it offhand.<br>I guess promises/async could be made cross-compatible by translating to continuations on the lisp side? Might get hairy.<br><br>Why was the "PS" short name a bad idea? Did it clash with anything?<br><br>Suggestions and comments are welcome.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 7, 2023 at 7:32 AM Vladimir Sedach <<a href="mailto:vas@oneofus.la">vas@oneofus.la</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
Monstara <<a href="mailto:monstara@gmail.com" target="_blank">monstara@gmail.com</a>> writes:<br>
> there could be a discussion whether to "modernize" parenscript, since<br>
> ECMAScript moves faster than is customary in Lisp.<br>
> I have started studying and playing with the parenscript code, and I am<br>
> interested in adding some newer ECMA features.<br>
><br>
> First off, let me say that I was unable to call (super) inside a<br>
> constructor, the way paren6 works (since the prototype is explicitly set<br>
> after the class function is declared). Therefore I feel it would be better<br>
> if the compiler itself supports js classes.<br>
> Once I get better acquainted with the compiler, would there be an interest<br>
> in other ECMA features being added? I don't know, maybe async? Or something<br>
> else. I'm open to suggestions.<br>
<br>
There are a few things to consider. With ES5 it was straightforward<br>
to ensure "Parenscript code can run almost identically on both the<br>
browser (as JavaScript) and server (as Common Lisp)." ES6 and<br>
especially ES7 make this a dubious goal, because of promises and<br>
async. Would you really want to write JS-style async code in Common<br>
Lisp? Would you really want to write JS-style async code at all?<br>
<br>
A few big projects used Parenscript for server-side Node.js<br>
deployment long before ES6, so obviously some people think it's a<br>
good idea.<br>
<br>
In terms of backward compatibility, it would probably mean forking<br>
the project - you would want to introduce package names like<br>
parenscript7, parenscript8, whatever new ECMA iteration is referred<br>
to; instead of using the *js-target-version* special variable.<br>
Dropping other stuff like the short name "PS" package (that was such<br>
a bad idea in hindsight) and having people use package-local<br>
nicknames; removing deprecated keywords such as "with"; other<br>
backwards-incompatible changes should also be a priority.<br>
<br>
--<br>
Vladimir Sedach<br>
</blockquote></div>