Hi, I am quite impressed by ParenScript. I installed it last August, but only recently I started playing with it. Some observations/comments : - js-script was in the Aug-2007 release but now it has been deprecated. By what has it been replaced ? - the js-script didn't work with with-html-output of cl-who, so I wrote my own macro js-script to do the script-tag + CDATA stuff which is still required for scripts in the header - the tutorial (Aug-28, 2007 p3) still refers to js-script
-Wout
Hi, I am looking for examples that show how lisp data can be passed to ps scripts. E.g. : I would like that (let ((x 1)) (ps:ps (setf y x))) is translated into : "y = 1;" in other words, how do I refer from within a parenscript construct to the lisp environment to collect a value ? Many thanks, -Wout
Hi Wout,
On Mon, 17 Mar 2008 23:56:34 +0000 Wout Perquin hedres@skynet.be wrote:
Hi, I am looking for examples that show how lisp data can be passed to ps scripts. E.g. : I would like that (let ((x 1)) (ps:ps (setf y x))) is translated into : "y = 1;" in other words, how do I refer from within a parenscript construct to the lisp environment to collect a value ? Many thanks, -Wout
I use ps:ps* like so;
(let ((x 1)) (ps:ps* `(setf y ,x)))
- sim
There is also the 'lisp macro which can be used from inside a Parenscript expression:
(ps:ps (setf y (lisp (* 2 2)))) => "y = 4;"
This allows your example to work if we declare x special:
(let ((x 1)) (declare (special x)) (ps:ps (setf y (lisp x)))) => "y = 1;"
But it doesn't pick up the lexical environment:
(let ((x 1)) (ps:ps (setf y (lisp x)))) => [Condition of type UNBOUND-VARIABLE]
This is true even when PS is the current package. Can anyone (Vladimir?) explain whether it has to be this way? Or could PS be extended to pick up lexical bindings as well?
Daniel
On Mon, Mar 17, 2008 at 4:25 PM, Simon Cusack scusack@fastmail.com.au wrote:
Hi Wout,
On Mon, 17 Mar 2008 23:56:34 +0000 Wout Perquin hedres@skynet.be wrote:
Hi, I am looking for examples that show how lisp data can be passed to ps scripts. E.g. : I would like that (let ((x 1)) (ps:ps (setf y x))) is translated into : "y = 1;" in other words, how do I refer from within a parenscript construct to the lisp environment to collect a value ? Many thanks, -Wout
I use ps:ps* like so;
(let ((x 1)) (ps:ps* `(setf y ,x)))
- sim
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
But it doesn't pick up the lexical environment:
(let ((x 1)) (ps:ps (setf y (lisp x)))) => [Condition of type UNBOUND-VARIABLE]
This is true even when PS is the current package. Can anyone (Vladimir?) explain whether it has to be this way? Or could PS be extended to pick up lexical bindings as well?
you may find the following example interesting. it's a similar issue for sql and lisp unquoting handled by the [] reader and the sql compile machinery in cl-rdbms.
the idea in short: [] reads its body into an sexp (a macrocall to a macro named SQL, this is important to keep backquote work inside the [] reader). commas and ,@ on the first level of depth inside the [] reader are read into a special form (sql-unquote (something to be evaled in lisp) splicedp). then the SQL macro at macroexpand time parses its sexp body into an SQL AST (clos objects) and then reduces everything it can into a constant string. naturally the body of sql-unquote AST nodes are emitted inline as code.
http://common-lisp.net/project/cl-rdbms/showcase.html
a similar approach could work for js compilation and js would probably benefit even more then sql. just wild guessing here, but i think this scheme would speed up ps compilation by a few magnitudes and reduce consing to a fraction of the current. (there was plenty of room for optimization in the old parenscript, i've divided it by 100 already in the old repo... :)
if we (cl-dwim guys) had infinite time we would do it ourselves, but i hope someone will pick up the idea and do it for ps... ;)
if we (cl-dwim guys) had infinite time we would do it ourselves, but i hope someone will pick up the idea and do it for ps... ;)
I agree this is the right way to go. Not only would it provide for more meaningful embedding of PS code in CL code (to answer Daniel's earlier query, the "lisp" macro evaluates its arguments at PS macro-expansion time (compile time, ie every time ps* gets called) via eval, hence it has no access to anything but the dynamic environment of the ps* call), but it would also obviate any need for PS output caching mechanisms (I know at least one instance of this has already been implemented in a PS application).
I might have a large chunk of time available over New Year's to work on this. I'd like to make a release before rewriting the compiler though. Please get your suggestions and bugfixes for the next release in soon!
Vladimir
-- attila _______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Just pushed a patch out that does compilation to strings at macro expansion-time for the PS and PS-INLINE macros as opposed expanding to PS*. There are some changes to the compilation interface, but the important difference is that now the LISP special form behaves differently for PS (has access to the lexical environment) vs. PS* (dynamic environment only). So using LISP inside PS* is now exactly like using EVAL when it comes to which environment the escaped CL code has access to.
Vladimir
On Sun, Dec 7, 2008 at 10:47 PM, Vladimir Sedach vsedach@gmail.com wrote:
if we (cl-dwim guys) had infinite time we would do it ourselves, but i hope someone will pick up the idea and do it for ps... ;)
I agree this is the right way to go. Not only would it provide for more meaningful embedding of PS code in CL code (to answer Daniel's earlier query, the "lisp" macro evaluates its arguments at PS macro-expansion time (compile time, ie every time ps* gets called) via eval, hence it has no access to anything but the dynamic environment of the ps* call), but it would also obviate any need for PS output caching mechanisms (I know at least one instance of this has already been implemented in a PS application).
I might have a large chunk of time available over New Year's to work on this. I'd like to make a release before rewriting the compiler though. Please get your suggestions and bugfixes for the next release in soon!
Vladimir
-- attila _______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Does that mean something like this would work?
(let ((a "example")) (js (alert (lisp a))))
Cheers, Dave.
Just pushed a patch out that does compilation to strings at macro expansion-time for the PS and PS-INLINE macros as opposed expanding to PS*. There are some changes to the compilation interface, but the important difference is that now the LISP special form behaves differently for PS (has access to the lexical environment) vs. PS* (dynamic environment only). So using LISP inside PS* is now exactly like using EVAL when it comes to which environment the escaped CL code has access to.
Vladimir
On Sun, Dec 7, 2008 at 10:47 PM, Vladimir Sedach vsedach@gmail.com wrote:
if we (cl-dwim guys) had infinite time we would do it ourselves, but i hope someone will pick up the idea and do it for ps... ;)
I agree this is the right way to go. Not only would it provide for more meaningful embedding of PS code in CL code (to answer Daniel's earlier query, the "lisp" macro evaluates its arguments at PS macro-expansion time (compile time, ie every time ps* gets called) via eval, hence it has no access to anything but the dynamic environment of the ps* call), but it would also obviate any need for PS output caching mechanisms (I know at least one instance of this has already been implemented in a PS application).
I might have a large chunk of time available over New Year's to work on this. I'd like to make a release before rewriting the compiler though. Please get your suggestions and bugfixes for the next release in soon!
Vladimir
-- attila _______________________________________________ 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
Yes, that's exactly it.
Vladimir
On Thu, Jan 15, 2009 at 6:58 PM, David Barker kzar@kzar.co.uk wrote:
Does that mean something like this would work?
(let ((a "example")) (js (alert (lisp a))))
Cheers, Dave.
Just pushed a patch out that does compilation to strings at macro expansion-time for the PS and PS-INLINE macros as opposed expanding to PS*. There are some changes to the compilation interface, but the important difference is that now the LISP special form behaves differently for PS (has access to the lexical environment) vs. PS* (dynamic environment only). So using LISP inside PS* is now exactly like using EVAL when it comes to which environment the escaped CL code has access to.
Vladimir
On Sun, Dec 7, 2008 at 10:47 PM, Vladimir Sedach vsedach@gmail.com wrote:
if we (cl-dwim guys) had infinite time we would do it ourselves, but i hope someone will pick up the idea and do it for ps... ;)
I agree this is the right way to go. Not only would it provide for more meaningful embedding of PS code in CL code (to answer Daniel's earlier query, the "lisp" macro evaluates its arguments at PS macro-expansion time (compile time, ie every time ps* gets called) via eval, hence it has no access to anything but the dynamic environment of the ps* call), but it would also obviate any need for PS output caching mechanisms (I know at least one instance of this has already been implemented in a PS application).
I might have a large chunk of time available over New Year's to work on this. I'd like to make a release before rewriting the compiler though. Please get your suggestions and bugfixes for the next release in soon!
Vladimir
-- attila _______________________________________________ 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 mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Ahh great work that was a sticking point I had with Parenscript, I will upgrade in a min.
Cheers, Dave.
Yes, that's exactly it.
Vladimir
On Thu, Jan 15, 2009 at 6:58 PM, David Barker kzar@kzar.co.uk wrote:
Does that mean something like this would work?
(let ((a "example")) (js (alert (lisp a))))
Cheers, Dave.
Just pushed a patch out that does compilation to strings at macro expansion-time for the PS and PS-INLINE macros as opposed expanding to PS*. There are some changes to the compilation interface, but the important difference is that now the LISP special form behaves differently for PS (has access to the lexical environment) vs. PS* (dynamic environment only). So using LISP inside PS* is now exactly like using EVAL when it comes to which environment the escaped CL code has access to.
Vladimir
On Sun, Dec 7, 2008 at 10:47 PM, Vladimir Sedach vsedach@gmail.com wrote:
if we (cl-dwim guys) had infinite time we would do it ourselves, but i hope someone will pick up the idea and do it for ps... ;)
I agree this is the right way to go. Not only would it provide for more meaningful embedding of PS code in CL code (to answer Daniel's earlier query, the "lisp" macro evaluates its arguments at PS macro-expansion time (compile time, ie every time ps* gets called) via eval, hence it has no access to anything but the dynamic environment of the ps* call), but it would also obviate any need for PS output caching mechanisms (I know at least one instance of this has already been implemented in a PS application).
I might have a large chunk of time available over New Year's to work on this. I'd like to make a release before rewriting the compiler though. Please get your suggestions and bugfixes for the next release in soon!
Vladimir
-- attila _______________________________________________ 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 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
Hi Wout,
js-script produced s-expressions that were supposed to be interpreted by the net.html.generator library that comes with AllegroServe, which is why it didn't work with cl-who, and why I chose to remove it. Since I don't want to tie PS to any particular html generation facility, there is no replacement, so writing your own was the right thing to do. Since the tutorial does use AllegroServe and net.html.generator, I just defined a js-script macro in there. All of this information should probably be in the tutorial, or the documentation.
Thank you, Vladimir
On 3/2/08, Wout Perquin hedres@skynet.be wrote:
Hi, I am quite impressed by ParenScript. I installed it last August, but only recently I started playing with it. Some observations/comments :
- js-script was in the Aug-2007 release but now it has been deprecated.
By what has it been replaced ?
- the js-script didn't work with with-html-output of cl-who, so I wrote
my own macro js-script to do the script-tag + CDATA stuff which is still required for scripts in the header
- the tutorial (Aug-28, 2007 p3) still refers to js-script
-Wout
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel@common-lisp.net
-
Attila Lendvai -
Daniel Gackle -
David Barker -
Simon Cusack -
Vladimir Sedach -
Wout Perquin