Hello.
I am new in parenscript and only glanced through the documentation on the project page.
As I understand parenscript source is compiled to javascript using a CL implemented compiler.
It's interesting, how difficult it is to have the same compiler implemented on javascript (i.e. on parenscript itself).
As parenscript is a subset of CL, in theory it mitght be not difficult.
The goal - is to have a browser only Lisp implementation, that can work without hunchentoot. To include parenscript scripts onto browser directly, redefine functions interactively and so on.
What do you think?
Best regards, - Anton
There is a lisp (similar to cl) implementation on javascript that works in the browser: https://github.com/manuel/edgelisp
You might want to look at that.
-- andy
On Wed, Jul 27, 2011 at 7:24 AM, Anton Vodonosov avodonosov@yandex.ruwrote:
Hello.
I am new in parenscript and only glanced through the documentation on the project page.
As I understand parenscript source is compiled to javascript using a CL implemented compiler.
It's interesting, how difficult it is to have the same compiler implemented on javascript (i.e. on parenscript itself).
As parenscript is a subset of CL, in theory it mitght be not difficult.
The goal - is to have a browser only Lisp implementation, that can work without hunchentoot. To include parenscript scripts onto browser directly, redefine functions interactively and so on.
What do you think?
Best regards,
- Anton
parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Currently Parenscript uses some things from Common Lisp that aren't in Parenscript. The three approaches to make PS self-hosting are:
1. Rewrite PS code in a DSL that can be compiled with Parenscript. For example, replace car/cdr/etc. with destructuring and templating macros that translate to car/cdr for CL and array access in JS. Then on the JS side you'd construct your code from arrays instead of conses. The only problematic thing is symbol representation.
2. Implement the missing CL features as a run-time library (add a cons prototype with car/cdr methods).
3. Make a Common Lisp implementation that runs in JavaScript.
I think the last option is the most overall useful, and the most fun to do. Parenscript then would (along with an existing CL implementation) act as a "syslisp"/bootstrapping dialect and cross-compiler. Red Daly already has large parts of the needed CL runtime implemented in his PSOS project (https://github.com/gonzojive/paren-psos).
How useful would Parenscript be in the browser? My guess is not very. After all, it will just be a macro pre-processor over JavaScript's eval, and anything you can do with that you're better off doing with closures.
OTOH having a full Common Lisp on the browser (*with* a working ASDF) would be pretty sweet. It would also be nice to have the full-featured JS environments (V8, Rhino, SpiderMonkey) as another target for CL deployment.
Vladimir
On Wed, Jul 27, 2011 at 7:24 AM, Anton Vodonosov avodonosov@yandex.ru wrote:
Hello.
I am new in parenscript and only glanced through the documentation on the project page.
As I understand parenscript source is compiled to javascript using a CL implemented compiler.
It's interesting, how difficult it is to have the same compiler implemented on javascript (i.e. on parenscript itself).
As parenscript is a subset of CL, in theory it mitght be not difficult.
The goal - is to have a browser only Lisp implementation, that can work without hunchentoot. To include parenscript scripts onto browser directly, redefine functions interactively and so on.
What do you think?
Best regards,
- Anton
parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
< It would also be nice to have the full-featured JS environments (V8, Rhino, SpiderMonkey) as another target for CL deployment. >
I think this is going to become increasingly important as the JS implementations improve. The recent release of Clojurescript is an indicator.
We've actually switched Skysheet to using PS server-side as well as client-side so we can deploy to V8 on the server. There are three reasons for this:
1) it eliminates the impedance mismatch between our CL code and our PS code, which was a drag on development (example: JS's hash objects don't have a very good counterpart in CL; neither CL hashtables nor plists/alists are a great substitute);
2) we get better performance from V8 than we do from SBCL. (That's for unoptimized CL. Optimized CL would do much better of course, but that would worsen the impedance mismatch described above;
3) interoperability with JS gives some desired conveniences, like V8's fast JSON support and Node.js for non-blocking i/o.
A full CL-in-JS would open the door to an all-CL system rather than an all-JS one. Either would be better than straddling the two. Would we switch? Hard to say.
On Wed, Jul 27, 2011 at 1:56 PM, Vladimir Sedach vsedach@gmail.com wrote:
Currently Parenscript uses some things from Common Lisp that aren't in Parenscript. The three approaches to make PS self-hosting are:
- Rewrite PS code in a DSL that can be compiled with Parenscript. For
example, replace car/cdr/etc. with destructuring and templating macros that translate to car/cdr for CL and array access in JS. Then on the JS side you'd construct your code from arrays instead of conses. The only problematic thing is symbol representation.
- Implement the missing CL features as a run-time library (add a cons
prototype with car/cdr methods).
- Make a Common Lisp implementation that runs in JavaScript.
I think the last option is the most overall useful, and the most fun to do. Parenscript then would (along with an existing CL implementation) act as a "syslisp"/bootstrapping dialect and cross-compiler. Red Daly already has large parts of the needed CL runtime implemented in his PSOS project (https://github.com/gonzojive/paren-psos).
How useful would Parenscript be in the browser? My guess is not very. After all, it will just be a macro pre-processor over JavaScript's eval, and anything you can do with that you're better off doing with closures.
OTOH having a full Common Lisp on the browser (*with* a working ASDF) would be pretty sweet. It would also be nice to have the full-featured JS environments (V8, Rhino, SpiderMonkey) as another target for CL deployment.
Vladimir
On Wed, Jul 27, 2011 at 7:24 AM, Anton Vodonosov avodonosov@yandex.ru wrote:
Hello.
I am new in parenscript and only glanced through the documentation on the
project page.
As I understand parenscript source is compiled to javascript using a CL
implemented compiler.
It's interesting, how difficult it is to have the same compiler
implemented on javascript (i.e. on parenscript itself).
As parenscript is a subset of CL, in theory it mitght be not difficult.
The goal - is to have a browser only Lisp implementation, that can work
without hunchentoot. To include parenscript
scripts onto browser directly, redefine functions interactively and so
on.
What do you think?
Best regards,
- Anton
parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
I've been meaning to drop a line here for a while, but this seems as opportune as any other time. I'm currently interning at Mozilla and my project should make targeting JS easier whether from PS or eventually from CL. It requires some buy-in on the side of the compiler, but I think it is worth it.
https://wiki.mozilla.org/DevTools/Features/SourceMap
_Nick_
On Wed, Jul 27, 2011 at 1:47 PM, Daniel Gackle danielgackle@gmail.comwrote:
< It would also be nice to have the full-featured JS environments (V8, Rhino, SpiderMonkey) as another target for CL deployment. >
I think this is going to become increasingly important as the JS implementations improve. The recent release of Clojurescript is an indicator.
We've actually switched Skysheet to using PS server-side as well as client-side so we can deploy to V8 on the server. There are three reasons for this:
- it eliminates the impedance mismatch between our CL code and our PS
code, which was a drag on development (example: JS's hash objects don't have a very good counterpart in CL; neither CL hashtables nor plists/alists are a great substitute);
- we get better performance from V8 than we do from SBCL. (That's for
unoptimized CL. Optimized CL would do much better of course, but that would worsen the impedance mismatch described above;
- interoperability with JS gives some desired conveniences, like V8's
fast JSON support and Node.js for non-blocking i/o.
A full CL-in-JS would open the door to an all-CL system rather than an all-JS one. Either would be better than straddling the two. Would we switch? Hard to say.
On Wed, Jul 27, 2011 at 1:56 PM, Vladimir Sedach vsedach@gmail.comwrote:
Currently Parenscript uses some things from Common Lisp that aren't in Parenscript. The three approaches to make PS self-hosting are:
- Rewrite PS code in a DSL that can be compiled with Parenscript. For
example, replace car/cdr/etc. with destructuring and templating macros that translate to car/cdr for CL and array access in JS. Then on the JS side you'd construct your code from arrays instead of conses. The only problematic thing is symbol representation.
- Implement the missing CL features as a run-time library (add a cons
prototype with car/cdr methods).
- Make a Common Lisp implementation that runs in JavaScript.
I think the last option is the most overall useful, and the most fun to do. Parenscript then would (along with an existing CL implementation) act as a "syslisp"/bootstrapping dialect and cross-compiler. Red Daly already has large parts of the needed CL runtime implemented in his PSOS project (https://github.com/gonzojive/paren-psos).
How useful would Parenscript be in the browser? My guess is not very. After all, it will just be a macro pre-processor over JavaScript's eval, and anything you can do with that you're better off doing with closures.
OTOH having a full Common Lisp on the browser (*with* a working ASDF) would be pretty sweet. It would also be nice to have the full-featured JS environments (V8, Rhino, SpiderMonkey) as another target for CL deployment.
Vladimir
On Wed, Jul 27, 2011 at 7:24 AM, Anton Vodonosov avodonosov@yandex.ru wrote:
Hello.
I am new in parenscript and only glanced through the documentation on
the project page.
As I understand parenscript source is compiled to javascript using a CL
implemented compiler.
It's interesting, how difficult it is to have the same compiler
implemented on javascript (i.e. on parenscript itself).
As parenscript is a subset of CL, in theory it mitght be not difficult.
The goal - is to have a browser only Lisp implementation, that can work
without hunchentoot. To include parenscript
scripts onto browser directly, redefine functions interactively and so
on.
What do you think?
Best regards,
- Anton
parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
This is great to hear! It's a feature I have wanted for a long time.
On Thu, Jul 28, 2011 at 12:50 PM, Nick Fitzgerald fitzgen@gmail.com wrote:
I've been meaning to drop a line here for a while, but this seems as opportune as any other time. I'm currently interning at Mozilla and my project should make targeting JS easier whether from PS or eventually from CL. It requires some buy-in on the side of the compiler, but I think it is worth it.
https://wiki.mozilla.org/DevTools/Features/SourceMap
_Nick_
On Wed, Jul 27, 2011 at 1:47 PM, Daniel Gackle danielgackle@gmail.comwrote:
< It would also be nice to have the full-featured JS environments (V8, Rhino, SpiderMonkey) as another target for CL deployment. >
I think this is going to become increasingly important as the JS implementations improve. The recent release of Clojurescript is an indicator.
We've actually switched Skysheet to using PS server-side as well as client-side so we can deploy to V8 on the server. There are three reasons for this:
- it eliminates the impedance mismatch between our CL code and our PS
code, which was a drag on development (example: JS's hash objects don't have a very good counterpart in CL; neither CL hashtables nor plists/alists are a great substitute);
- we get better performance from V8 than we do from SBCL. (That's for
unoptimized CL. Optimized CL would do much better of course, but that would worsen the impedance mismatch described above;
- interoperability with JS gives some desired conveniences, like V8's
fast JSON support and Node.js for non-blocking i/o.
A full CL-in-JS would open the door to an all-CL system rather than an all-JS one. Either would be better than straddling the two. Would we switch? Hard to say.
On Wed, Jul 27, 2011 at 1:56 PM, Vladimir Sedach vsedach@gmail.comwrote:
Currently Parenscript uses some things from Common Lisp that aren't in Parenscript. The three approaches to make PS self-hosting are:
- Rewrite PS code in a DSL that can be compiled with Parenscript. For
example, replace car/cdr/etc. with destructuring and templating macros that translate to car/cdr for CL and array access in JS. Then on the JS side you'd construct your code from arrays instead of conses. The only problematic thing is symbol representation.
- Implement the missing CL features as a run-time library (add a cons
prototype with car/cdr methods).
- Make a Common Lisp implementation that runs in JavaScript.
I think the last option is the most overall useful, and the most fun to do. Parenscript then would (along with an existing CL implementation) act as a "syslisp"/bootstrapping dialect and cross-compiler. Red Daly already has large parts of the needed CL runtime implemented in his PSOS project (https://github.com/gonzojive/paren-psos).
How useful would Parenscript be in the browser? My guess is not very. After all, it will just be a macro pre-processor over JavaScript's eval, and anything you can do with that you're better off doing with closures.
OTOH having a full Common Lisp on the browser (*with* a working ASDF) would be pretty sweet. It would also be nice to have the full-featured JS environments (V8, Rhino, SpiderMonkey) as another target for CL deployment.
Vladimir
On Wed, Jul 27, 2011 at 7:24 AM, Anton Vodonosov avodonosov@yandex.ru wrote:
Hello.
I am new in parenscript and only glanced through the documentation on
the project page.
As I understand parenscript source is compiled to javascript using a CL
implemented compiler.
It's interesting, how difficult it is to have the same compiler
implemented on javascript (i.e. on parenscript itself).
As parenscript is a subset of CL, in theory it mitght be not difficult.
The goal - is to have a browser only Lisp implementation, that can work
without hunchentoot. To include parenscript
scripts onto browser directly, redefine functions interactively and so
on.
What do you think?
Best regards,
- Anton
parenscript-devel mailing list parenscript-devel@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel@common-lisp.net
-
Andy Peterson -
Anton Vodonosov -
Daniel Gackle -
Nick Fitzgerald -
Vladimir Sedach