Vladimir Sedach wrote:
>> 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@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
>>
>
> _______________________________________________
> parenscript-devel mailing list
>
parenscript-devel@common-lisp.net
>
http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>