[parenscript-devel] New Parenscript release.

[Daniel Gackle]

< Is it a Lisp-1 or Lisp-2? >

PS isn't a Lisp, as per our discussion. The semantics here are JS's, and JS
is always a JS-1.

< explicitly RETURN values from functions -- and this is something I keep
tripping over frequently >

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.

Vladimir, have you ever thought of or tried to get RETURN out of PS? What
are the main challenges?


On Fri, Oct 9, 2009 at 6:25 AM, Chaitanya Gupta <mail at chaitanyagupta.com>wrote:

> 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/
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/parenscript-devel/attachments/20091009/f20ed209/attachment.html>