Hi,
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. I have started a prototype of classes already, but I've yet to learn.
Any pointers would be appreciated.
Regards, Mois
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
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 vas@oneofus.la wrote:
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
parenscript-devel@common-lisp.net
-
Monstara -
Vladimir Sedach