[parenscript-devel] New Parenscript release.

Daniel Gackle danielgackle at gmail.com
Thu Oct 8 15:39:14 UTC 2009


It would be hard to make PS a complete CL without giving up on producing
efficient and readable JS, which is what makes PS so suitable for production
systems.

You can get close, though. We write most of our app in a subset of CL that
compiles to PS using a bunch of macros we wrote. I've been toying with the
idea of open-sourcing these. The problem is that, while they work great for
us, they're not perfect for the general case, which is what PS really needs
to address.

An example of the impedance mismatch is how to implement car, cdr, etc. You
could roll your own lists, but these would be slow and  hard to debug. So we
map CL lists to JS arrays, using slice for cdr and so on. But JS arrays
aren't lists, so this is far from a perfect mapping. It's not really
suitable for a general Lisp.

Speaking of efficient/readable JS, a few months ago I partially objected to
the implementation of lexical scoping on the grounds that attaching a gensym
suffix to every lexical variable inhibited readability. It's worth
mentioning that Vladimir completely fixed this by (if I understand
correctly) making PS put suffixes only on variables where necessary to
disambiguate them. As a result, a powerful feature was added without
compromising the quality of the generated code. A particularly impressive
piece of work.

Daniel

On Thu, Oct 8, 2009 at 5:42 AM, Chaitanya Gupta <mail at chaitanyagupta.com>wrote:

> Vladimir Sedach wrote:
> > PS is a translator from Common Lisp to JavaScript. The project stopped
> > being an s-expression syntax for JS quite a while ago.
> >
>
> That, for me atleast, is great news. I had been wondering for sometime
> which direction Parenscript was headed in, and have had a CL->JS
> compiler high on my wishlist.
>
> Do you plan to make it a complete ANSI CL to JS compiler? (Complete
> being whatever's allowed within the limits of the browser's security
> model e.g. file and socket operations might not work)
>
> Does PS aim to become for CL like gwt is for Java? e.g. generating JS
> which works correctly across all the major browsers.
>
> These are a few questions I have had for sometime -- I would really like
> to see something akin to gwt for CL.
>
> Chaitanya
>
> >> What if there were a special form to explicitly allow a Lisp symbol
> >> through unmodified? This would be a bit different than the current
> >> |:foo| syntax (the :-escape applies to whatever portion of the
> >> split symbol it prefixes e.g. |:foo.Bar.:baaZ| -> foo.bar.baaZ).
> >
> > This isn't the issue with foo.bar syntax. The problem is that putting
> > foo.bar in Parenscript (as opposed to outside the PS compiler) fails
> > in the presence of symbol macros for either foo or bar. Even ignoring
> > other possible undesirable consequences, this makes it a big pain to
> > implement 'let' with real lexical scoping efficiently or readably, and
> > makes code inspection by conventional tools impossible. The whole
> > issue is centered around symbol identity and the abuse of symbol
> > names.
> >
> >> Prefix syntax makes method calling a bit awkward and (.method ...)
> >> syntax makes method calls a bit more CLOSish in appearance. I am neutral
> >> on its value, but since parenscript has supported this for years and a
> >> lot of code is relying on it the cost of removing it is high.
> >
> > The dot syntax is a design mistake that makes what should be trivial
> > code transformation hard. This has consequences for both the PS
> > compiler (keeping it would make it more complicated than it needs to
> > be) and just as importantly as for the code being compiled. If someone
> > wants to upgrade their project to use the latest version of
> > Parenscript, I think it's ok to ask them to fix what are essentially
> > bugs in their code. The only regrettable thing is that these bugs were
> > encouraged by previous versions of Parenscript as desirable
> > programming style.
> >
> > Vladimir
> >
> > _______________________________________________
> > parenscript-devel mailing list
> > parenscript-devel at common-lisp.net
> > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
> >
>
>
> --
> http://chaitanyagupta.com/blog/
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/parenscript-devel/attachments/20091008/1a3141ee/attachment.html>


More information about the parenscript-devel mailing list