< Is it a Lisp-1 or Lisp-2? ><br><br>PS isn't a Lisp, as per our discussion. The semantics here are JS's, and JS is always a JS-1.<br><br>< explicitly RETURN values from
functions -- and this is something I keep tripping over frequently ><br><br>This is a pain. We have an ugly RETURN% macro that does nothing in Lisp and expands to RETURN in PS. One of our goals is to figure out how to put these in automatically.<br>

<br>Vladimir, have you ever thought of or tried to get RETURN out of PS? What are the main challenges?<br><br><br><div class="gmail_quote">On Fri, Oct 9, 2009 at 6:25 AM, Chaitanya Gupta <span dir="ltr"><<a href="mailto:mail@chaitanyagupta.com">mail@chaitanyagupta.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Thanks for the replies -- Vladimir and Daniel. I take it that generating<br>
readable Javascript code remains one of the big goals of PS.<br>
<br>
And thanks for the inputs on gwt too -- there's some food for thought<br>
there for sure.<br>
<br>
A few more questions/suggestions:<br>
<br>
- Is it a Lisp-1 or Lisp-2? I see that FUNCALL seems to do the right<br>
thing in PS, but then again, the generated JS code doesn't have separate<br>
namespaces for variables and functions. Will PS remain a Lisp-1 going<br>
forward?<br>
<br>
- What about CLOS? I've noticed PSOS, which is part of the Suave project<br>
(though I haven't been able to try it out yet). Is there any plan to<br>
bring CLOS support into Parenscript?<br>
<br>
- One specific issue I have noticed with the little bit of PS hacking<br>
that I have done is that I have to explicitly RETURN values from<br>
functions -- and this is something I keep tripping over frequently. An<br>
implicit return would be more Lispish and much better, IMO.<br>
<font color="#888888"><br>
Chaitanya<br>
</font><div><div></div><div class="h5"><br>
Vladimir Sedach wrote:<br>
>> Do you plan to make it a complete ANSI CL to JS compiler? (Complete<br>
>> being whatever's allowed within the limits of the browser's security<br>
>> model e.g. file and socket operations might not work)<br>
><br>
> There are a lot of things in CL that don't make much sense in JS. Most<br>
> of it has to do with data structures and types. For example, there's<br>
> really no point in implementing linked lists in JavaScript since all<br>
> the other JS code uses arrays. Parenscript 'dolist' and 'loop' work on<br>
> JS arrays, and for most use cases have the same semantics as the CL<br>
> 'dolist' and 'loop'.<br>
><br>
> The goal of Parenscript is to cover the common case semantic overlaps<br>
> that exist between native or idiomatic/human-readable JavaScript code<br>
> and the CL "equivalent."<br>
><br>
> Not being based around native JS datatypes is where GWT and most<br>
> (all?) other *-to-JS compilers fail. As soon as you require weird<br>
> datatypes or boxed object you lose readability and compatibility with<br>
> other JS code. Luckily Common Lisp is rich enough where you don't need<br>
> to express everything in terms of a small set of orthogonal concepts<br>
> like recursion and pattern-matching, which pretty much condemns things<br>
> like SMLtoJs to generating weird JavaScript code.<br>
><br>
>> Does PS aim to become for CL like gwt is for Java? e.g. generating JS<br>
>> which works correctly across all the major browsers.<br>
><br>
> GWT's cross-browser support is fundamentally broken because it is<br>
> based on browser detection. The GWT developers are selling snake-oil<br>
> when they claim cross browser compatibility:<br>
> <a href="http://carcaddar.blogspot.com/2009/02/gwt-and-deferred-binding.html" target="_blank">http://carcaddar.blogspot.com/2009/02/gwt-and-deferred-binding.html</a><br>
><br>
> GWT does not support older browsers, most mobile browsers, and is<br>
> unlikely to work correctly on future browsers.<br>
><br>
> Parenscript actually doesn't come with anything specific to the<br>
> browser or DOM - by default it only generates JavaScript 1.3 code. How<br>
> you deal with DOM differences is up to you. There are projects using<br>
> Parenscript that do browser detection, there are projects that do<br>
> feature detection. I try to design my applications to only use the<br>
> subset of the DOM that works identically in all browsers.<br>
><br>
>> These are a few questions I have had for sometime -- I would really like<br>
>> to see something akin to gwt for CL.<br>
><br>
> The only other thing that gwt does besides compiling Java to JS is to<br>
> provide a library of UI widgets. I don't really see the value in doing<br>
> that. I recently had this opinion confirmed by the PhoneGap<br>
> (<a href="http://phonegap.com/" target="_blank">http://phonegap.com/</a>) guys - Brian LeRoux was highly critical of<br>
> widget UI libraries at a talk he gave at the Mobile Portland user's<br>
> group in August. So I'm not the only person holding this opinion.<br>
> There's nothing stopping you from using jQuery UI or ExtJS or any<br>
> other UI library if you want to (this is not the case with GWT, which<br>
> requires you to write wrappers for any JavaScript library you want to<br>
> use).<br>
><br>
> Vladimir<br>
><br>
>> Chaitanya<br>
>><br>
>>>> What if there were a special form to explicitly allow a Lisp symbol<br>
>>>> through unmodified? This would be a bit different than the current<br>
>>>> |:foo| syntax (the :-escape applies to whatever portion of the<br>
>>>> split symbol it prefixes e.g. |:foo.Bar.:baaZ| -> foo.bar.baaZ).<br>
>>> This isn't the issue with foo.bar syntax. The problem is that putting<br>
>>> foo.bar in Parenscript (as opposed to outside the PS compiler) fails<br>
>>> in the presence of symbol macros for either foo or bar. Even ignoring<br>
>>> other possible undesirable consequences, this makes it a big pain to<br>
>>> implement 'let' with real lexical scoping efficiently or readably, and<br>
>>> makes code inspection by conventional tools impossible. The whole<br>
>>> issue is centered around symbol identity and the abuse of symbol<br>
>>> names.<br>
>>><br>
>>>> Prefix syntax makes method calling a bit awkward and (.method ...)<br>
>>>> syntax makes method calls a bit more CLOSish in appearance. I am neutral<br>
>>>> on its value, but since parenscript has supported this for years and a<br>
>>>> lot of code is relying on it the cost of removing it is high.<br>
>>> The dot syntax is a design mistake that makes what should be trivial<br>
>>> code transformation hard. This has consequences for both the PS<br>
>>> compiler (keeping it would make it more complicated than it needs to<br>
>>> be) and just as importantly as for the code being compiled. If someone<br>
>>> wants to upgrade their project to use the latest version of<br>
>>> Parenscript, I think it's ok to ask them to fix what are essentially<br>
>>> bugs in their code. The only regrettable thing is that these bugs were<br>
>>> encouraged by previous versions of Parenscript as desirable<br>
>>> programming style.<br>
>>><br>
>>> Vladimir<br>
>>><br>
>>> _______________________________________________<br>
>>> parenscript-devel mailing list<br>
>>> <a href="mailto:parenscript-devel@common-lisp.net">parenscript-devel@common-lisp.net</a><br>
>>> <a href="http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
>>><br>
>><br>
>> --<br>
>> <a href="http://chaitanyagupta.com/blog/" target="_blank">http://chaitanyagupta.com/blog/</a><br>
>><br>
>> _______________________________________________<br>
>> parenscript-devel mailing list<br>
>> <a href="mailto:parenscript-devel@common-lisp.net">parenscript-devel@common-lisp.net</a><br>
>> <a href="http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
>><br>
><br>
> _______________________________________________<br>
> parenscript-devel mailing list<br>
> <a href="mailto:parenscript-devel@common-lisp.net">parenscript-devel@common-lisp.net</a><br>
> <a href="http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
><br>
<br>
<br>
</div></div>--<br>
<div><div></div><div class="h5"><a href="http://chaitanyagupta.com/blog/" target="_blank">http://chaitanyagupta.com/blog/</a><br>
<br>
_______________________________________________<br>
parenscript-devel mailing list<br>
<a href="mailto:parenscript-devel@common-lisp.net">parenscript-devel@common-lisp.net</a><br>
<a href="http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
</div></div></blockquote></div><br>