[parenscript-devel] New Parenscript release.

Fri Oct 9 12:25:59 UTC 2009

Thanks for the replies -- Vladimir and Daniel. I take it that generating 
readable Javascript code remains one of the big goals of PS.

And thanks for the inputs on gwt too -- there's some food for thought 
there for sure.

A few more questions/suggestions:

- Is it a Lisp-1 or Lisp-2? I see that FUNCALL seems to do the right 
thing in PS, but then again, the generated JS code doesn't have separate 
namespaces for variables and functions. Will PS remain a Lisp-1 going 
forward?

- What about CLOS? I've noticed PSOS, which is part of the Suave project 
(though I haven't been able to try it out yet). Is there any plan to 
bring CLOS support into Parenscript?

- One specific issue I have noticed with the little bit of PS hacking 
that I have done is that I have to explicitly RETURN values from 
functions -- and this is something I keep tripping over frequently. An 
implicit return would be more Lispish and much better, IMO.

Chaitanya

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

-- 
http://chaitanyagupta.com/blog/