Congratulations on the new release! This seems like a good time to ask: what (if any) are the next significant things that could and should be added to Parenscript? Put differently, what CL constructs are there that (a) haven't been tackled yet, and (b) have a reasonable mapping to JS? The latter is important to preserve the goals of efficient, readable, debuggable JS.
Any suggestions?
I nominate backquote/comma. At least at a 50,000 foot level, it seems like the sort of thing PS could do, and it's pretty obvious that it would be useful.
Daniel
I nominate backquote/comma. At least at a 50,000 foot level, it seems like the sort of thing PS could do, and it's pretty obvious that it would be useful.
That's a really cool idea.
The only two new features I have on the todo list right now are:
1. Use the 'with' statement to introduce proper scoping for closures. 2. Generalize the implicit return code transformation to work with assignment and arguments passed to functions.
These are both ideas borrowed from the scm2js compiler (http://hop.inria.fr/usr/local/lib/hop/2.0.0/weblets/home/articles/scheme2js/...).
There are tons of CL features and functions that can be implemented, but my plan is to only add new features by request. My plan for the next release is mainly to refactor the compiler, and split off the print subsystem into the JS-toolkit project (which will also include a JS parser).
Vladimir
Daniel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Sounds interesting. Just a quick note: if I recall correctly, the "with" statement is notorious for being slow in JS implementations. Something to watch out for.
On Sat, Feb 27, 2010 at 2:15 PM, Vladimir Sedach vsedach@gmail.com wrote:
I nominate backquote/comma. At least at a 50,000 foot level, it seems
like
the sort of thing PS could do, and it's pretty obvious that it would be useful.
That's a really cool idea.
The only two new features I have on the todo list right now are:
- Use the 'with' statement to introduce proper scoping for closures.
- Generalize the implicit return code transformation to work with
assignment and arguments passed to functions.
These are both ideas borrowed from the scm2js compiler ( http://hop.inria.fr/usr/local/lib/hop/2.0.0/weblets/home/articles/scheme2js/... ).
There are tons of CL features and functions that can be implemented, but my plan is to only add new features by request. My plan for the next release is mainly to refactor the compiler, and split off the print subsystem into the JS-toolkit project (which will also include a JS parser).
Vladimir
Daniel
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
There are tons of CL features and functions that can be implemented, but my plan is to only add new features by request.
I still think that the ability to send an object back and forth between client and server (while it always remembers what class it is an instance of) should become a standard part of PS. This would allow PS to compete with GWT.
If you want to find out if there is broad enough interest in requests such as mine, you could also let people vote on future features.
Greetings,
Axel
I think it's a good idea for a library. Maybe as an extensions to Red Daly's PSOS? In any case, that would be one more idea to steal from HOP (http://hop.inria.fr/), which I think was doing object sharing before, and in a better way, than GWT.
As far as freedom and democracy, if someone requests a feature and it seems like a good idea, I will implement it.
Vladimir
2010/2/27 Axel Rauschmayer axel@rauschma.de:
There are tons of CL features and functions that can be implemented, but my plan is to only add new features by request.
I still think that the ability to send an object back and forth between client and server (while it always remembers what class it is an instance of) should become a standard part of PS. This would allow PS to compete with GWT.
If you want to find out if there is broad enough interest in requests such as mine, you could also let people vote on future features.
Greetings,
Axel
-- Axel.Rauschmayer@ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Sounds good. I always feel a bit weird pushing my vision when I have no time to contribute. I think a few stars are currently aligning to make Common Lisp an intriguing platform:
- The JVM-based ABCL is making tremendous progress. - Parenscript can be used to write CL-based browser applications. - Web applications are becoming increasingly viable, Google's Chrome OS will probably plug many of the holes that still exist.
So, in the mid-term future, one might have a JVM-based CL environment that is easy to install and could use Bespin [1] as a cloud-based development environment.
Developing with GWT is pretty damn sweet (especially, because they have finally figured out how to do layout properly [2]). But CL as a language is so much better suited than Java for the kind of service-oriented APIs that one implements with GWT. Thus, a combination of ABCL and Parenscript would be a perfect replacement for GWT.
[1] https://bespin.mozillalabs.com/ [2] http://2ality.blogspot.com/2010/02/next-generation-of-web-application-ui.htm...
On Feb 28, 2010, at 23:46 , Vladimir Sedach wrote:
I think it's a good idea for a library. Maybe as an extensions to Red Daly's PSOS? In any case, that would be one more idea to steal from HOP (http://hop.inria.fr/), which I think was doing object sharing before, and in a better way, than GWT.
As far as freedom and democracy, if someone requests a feature and it seems like a good idea, I will implement it.
Developing with GWT is pretty damn sweet (especially, because they have finally figured out how to do layout properly [2]).
I wonder how they do that. One project I worked on did all the layout on the server side. If your connection is low latency it is reasonably fast. Other than doing things impossible with CSS, this approach is also immune to browser-specific layout bugs. There's no reason doing your own layout calculations can't be done on the browser.
But CL as a language is so much better suited than Java for the kind of service-oriented APIs that one implements with GWT. Thus, a combination of ABCL and Parenscript would be a perfect replacement for GWT.
Parenscript, your proposed object sharing system, and a nice way to interface that with ExtJS (best JS UI library IMO, but a pain to do anything dynamic with) would do everything that GWT does, in a much better way.
Vladimir
[1] https://bespin.mozillalabs.com/ [2] http://2ality.blogspot.com/2010/02/next-generation-of-web-application-ui.htm...
On Feb 28, 2010, at 23:46 , Vladimir Sedach wrote:
I think it's a good idea for a library. Maybe as an extensions to Red Daly's PSOS? In any case, that would be one more idea to steal from HOP (http://hop.inria.fr/), which I think was doing object sharing before, and in a better way, than GWT.
As far as freedom and democracy, if someone requests a feature and it seems like a good idea, I will implement it.
-- Axel.Rauschmayer@ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
On Sun, Feb 28, 2010 at 2:46 PM, Vladimir Sedach vsedach@gmail.com wrote:
I think it's a good idea for a library. Maybe as an extensions to Red Daly's PSOS? In any case, that would be one more idea to steal from HOP (http://hop.inria.fr/), which I think was doing object sharing before, and in a better way, than GWT.
I have got basic object sharing working for PSOS using a JSON-like scheme for encoding objects along with type information and circular reference. It's not documented well but it has been stable for 2 years or so: http://github.com/gonzojive/rjson If you request I can write up some documentation at some point.
I use RJSON as the serialization scheme but I do not have any transparent object sharing code at the moment (e.g. modifying an object on the client and committing the change to the server). But it's a start..
As far as other changes go, I would like to see Parenscript SLIMEified a bit. In particular I would like to see autocompletion when I type a function name (show the lambda list). M-. would be awesome. A REPL that hooked into a web browser (either via ajax on a web server or via a browser plug-in) would enhance the development process as well
-- Red
As far as freedom and democracy, if someone requests a feature and it seems like a good idea, I will implement it.
Vladimir
2010/2/27 Axel Rauschmayer axel@rauschma.de:
There are tons of CL features and functions that can be implemented, but my plan is to only add new features by request.
I still think that the ability to send an object back and forth between client and server (while it always remembers what class it is an instance of) should become a standard part of PS. This would allow PS to compete with GWT.
If you want to find out if there is broad enough interest in requests such as mine, you could also let people vote on future features.
Greetings,
Axel
-- Axel.Rauschmayer@ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/
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
parenscript-devel@common-lisp.net
-
Axel Rauschmayer -
Daniel Gackle -
Red Daly -
Vladimir Sedach