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
Vladimir Sedach wrote:That, for me atleast, is great news. I had been wondering for sometime
> PS is a translator from Common Lisp to JavaScript. The project stopped
> being an s-expression syntax for JS quite a while ago.
>
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@common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
http://chaitanyagupta.com/blog/
_______________________________________________
parenscript-devel mailing list
parenscript-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel