[parenscript-devel] New Parenscript release.

[Vladimir Sedach]

> 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)

There are a lot of things in CL that don't make much sense in JS. Most
of it has to do with data structures and types. For example, there's
really no point in implementing linked lists in JavaScript since all
the other JS code uses arrays. Parenscript 'dolist' and 'loop' work on
JS arrays, and for most use cases have the same semantics as the CL
'dolist' and 'loop'.

The goal of Parenscript is to cover the common case semantic overlaps
that exist between native or idiomatic/human-readable JavaScript code
and the CL "equivalent."

Not being based around native JS datatypes is where GWT and most
(all?) other *-to-JS compilers fail. As soon as you require weird
datatypes or boxed object you lose readability and compatibility with
other JS code. Luckily Common Lisp is rich enough where you don't need
to express everything in terms of a small set of orthogonal concepts
like recursion and pattern-matching, which pretty much condemns things
like SMLtoJs to generating weird JavaScript code.

> Does PS aim to become for CL like gwt is for Java? e.g. generating JS
> which works correctly across all the major browsers.

GWT's cross-browser support is fundamentally broken because it is
based on browser detection. The GWT developers are selling snake-oil
when they claim cross browser compatibility:
http://carcaddar.blogspot.com/2009/02/gwt-and-deferred-binding.html

GWT does not support older browsers, most mobile browsers, and is
unlikely to work correctly on future browsers.

Parenscript actually doesn't come with anything specific to the
browser or DOM - by default it only generates JavaScript 1.3 code. How
you deal with DOM differences is up to you. There are projects using
Parenscript that do browser detection, there are projects that do
feature detection. I try to design my applications to only use the
subset of the DOM that works identically in all browsers.

> These are a few questions I have had for sometime -- I would really like
> to see something akin to gwt for CL.

The only other thing that gwt does besides compiling Java to JS is to
provide a library of UI widgets. I don't really see the value in doing
that. I recently had this opinion confirmed by the PhoneGap
(http://phonegap.com/) guys - Brian LeRoux was highly critical of
widget UI libraries at a talk he gave at the Mobile Portland user's
group in August. So I'm not the only person holding this opinion.
There's nothing stopping you from using jQuery UI or ExtJS or any
other UI library if you want to (this is not the case with GWT, which
requires you to write wrappers for any JavaScript library you want to
use).

Vladimir

> 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
>