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