Thanks a lot for the response, Vladimir. The goal of generating valid Javascript and Lisp from the same code is commendable. I could not pull it off :) Definitely agree that the new project should be a fork. 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?"
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. 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? Async is not my goal, but I won't dismiss it offhand. I guess promises/async could be made cross-compatible by translating to continuations on the lisp side? Might get hairy. Why was the "PS" short name a bad idea? Did it clash with anything? Suggestions and comments are welcome. On Tue, Feb 7, 2023 at 7:32 AM Vladimir Sedach <[email protected]> wrote: > Hello, > > Monstara <[email protected]> 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 >
