Classes, updating parenscript

[Monstara]

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 at oneofus.la> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/parenscript-devel/attachments/20230222/6d2f6cfb/attachment.html>