[parenscript-devel] New Parenscript release.

[Chaitanya Gupta]

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/