Just ran across this one:
(ps (let ((abc (@ x :abc))) (funcall abc)))
=>
"var abc901 = x.abc; abc();"
Daniel
Vladimir,
I don't think we heard back about this bug. I've got an ugly workaround for it in my code, which it would be nice to get out of there. Do you think it will be hard to fix?
Daniel
On Mon, Mar 29, 2010 at 1:47 PM, Daniel Gackle danielgackle@gmail.comwrote:
Just ran across this one:
(ps (let ((abc (@ x :abc))) (funcall abc)))
=>
"var abc901 = x.abc; abc();"
Daniel
It won't. The reason I haven't addressed it yet is that I'm not done doing the PS compiler rewrite.
Vladimir
2010/4/15 Daniel Gackle danielgackle@gmail.com:
Vladimir, I don't think we heard back about this bug. I've got an ugly workaround for it in my code, which it would be nice to get out of there. Do you think it will be hard to fix? Daniel On Mon, Mar 29, 2010 at 1:47 PM, Daniel Gackle danielgackle@gmail.com wrote:
Just ran across this one: (ps (let ((abc (@ x :abc))) (funcall abc))) => "var abc901 = x.abc; abc();" Daniel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
When I run that through I get:
(ps (let ((abc (@ x :abc))) (funcall abc)))
=>
"var abc = x['abc']; abc();"
Are you maybe using an earlier version of PS?
Michael
On Wed, 2010-04-14 at 22:04 -0600, Daniel Gackle wrote:
Vladimir,
I don't think we heard back about this bug. I've got an ugly workaround for it in my code, which it would be nice to get out of there. Do you think it will be hard to fix?
Daniel
On Mon, Mar 29, 2010 at 1:47 PM, Daniel Gackle danielgackle@gmail.com wrote: Just ran across this one:
(ps (let ((abc (@ x :abc))) (funcall abc))) => "var abc901 = x.abc; abc();" Daniel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Good catch! I should have written:
(ps (let ((abc (@ x abc))) (funcall abc)))
=>
"var abc901 = x.abc; abc();"
I gave the wrong version because we have a customized @ that plays games with symbols and keywords. But the above runs in pure PS and is still a bug, I would think.
Daniel
On Thu, Apr 15, 2010 at 9:48 PM, Michael Compton < michael.compton@littleedge.co.uk> wrote:
When I run that through I get:
(ps (let ((abc (@ x :abc))) (funcall abc)))
=>
"var abc = x['abc']; abc();"
Are you maybe using an earlier version of PS?
Michael
On Wed, 2010-04-14 at 22:04 -0600, Daniel Gackle wrote:
Vladimir,
I don't think we heard back about this bug. I've got an ugly workaround for it in my code, which it would be nice to get out of there. Do you think it will be hard to fix?
Daniel
On Mon, Mar 29, 2010 at 1:47 PM, Daniel Gackle danielgackle@gmail.com wrote: Just ran across this one:
(ps (let ((abc (@ x :abc))) (funcall abc))) => "var abc901 = x.abc; abc();" 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
Just pushed a fixed. I also did a bunch of work on the compiler; let me know if anything else breaks.
Vladimir
2010/4/16 Daniel Gackle danielgackle@gmail.com:
Good catch! I should have written: (ps (let ((abc (@ x abc))) (funcall abc))) => "var abc901 = x.abc; abc();" I gave the wrong version because we have a customized @ that plays games with symbols and keywords. But the above runs in pure PS and is still a bug, I would think. Daniel
On Thu, Apr 15, 2010 at 9:48 PM, Michael Compton michael.compton@littleedge.co.uk wrote:
When I run that through I get:
(ps (let ((abc (@ x :abc))) (funcall abc)))
=>
"var abc = x['abc']; abc();"
Are you maybe using an earlier version of PS?
Michael
On Wed, 2010-04-14 at 22:04 -0600, Daniel Gackle wrote:
Vladimir,
I don't think we heard back about this bug. I've got an ugly workaround for it in my code, which it would be nice to get out of there. Do you think it will be hard to fix?
Daniel
On Mon, Mar 29, 2010 at 1:47 PM, Daniel Gackle danielgackle@gmail.com wrote: Just ran across this one:
(ps (let ((abc (@ x :abc))) (funcall abc)))
=>
"var abc901 = x.abc; abc();"
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
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
I'll run a diff on our generated JS tonight and report back.
For those of us who are curious, could you talk a bit about the work you did on the compiler?
Thanks Vladimir, Daniel
On Sun, Apr 18, 2010 at 5:34 PM, Vladimir Sedach vsedach@gmail.com wrote:
Just pushed a fixed. I also did a bunch of work on the compiler; let me know if anything else breaks.
Vladimir
2010/4/16 Daniel Gackle danielgackle@gmail.com:
Good catch! I should have written: (ps (let ((abc (@ x abc))) (funcall abc))) => "var abc901 = x.abc; abc();" I gave the wrong version because we have a customized @ that plays games with symbols and keywords. But the above runs in pure PS and is still a
bug,
I would think. Daniel
On Thu, Apr 15, 2010 at 9:48 PM, Michael Compton michael.compton@littleedge.co.uk wrote:
When I run that through I get:
(ps (let ((abc (@ x :abc))) (funcall abc)))
=>
"var abc = x['abc']; abc();"
Are you maybe using an earlier version of PS?
Michael
On Wed, 2010-04-14 at 22:04 -0600, Daniel Gackle wrote:
Vladimir,
I don't think we heard back about this bug. I've got an ugly workaround for it in my code, which it would be nice to get out of there. Do you think it will be hard to fix?
Daniel
On Mon, Mar 29, 2010 at 1:47 PM, Daniel Gackle danielgackle@gmail.com wrote: Just ran across this one:
(ps (let ((abc (@ x :abc))) (funcall abc))) => "var abc901 = x.abc; abc();" 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
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
+1, as they say...
++Thanks,
John :^P
On Mon, Apr 19, 2010 at 12:42 AM, Daniel Gackle danielgackle@gmail.com wrote:
For those of us who are curious, could you talk a bit about the work you did on the compiler? Thanks Vladimir, Daniel
This work was removing the last of the old-style hacks from the compiler to clearly separate PS into three parts: the compiler itself, the special forms code, and the printer. This reduces code size and dependencies significantly, but the ultimate goal (which has mostly been achieved) is to provide an intermediary S-exp representation of JavaScript code that is directly and efficiently executable as Common Lisp code.
In the future I'll be moving the printer code to a separate project, which will also have a parser from JavaScript to this intermediary representation. That project will serve as a useful base for JS code transformation tools, and I am planning to write a JS->CL compiler on top.
One user-visible change I made in the latest patches is to encourage use of CL equality predicates ('==' and '===' are still there but marked as deprecated).
Vladimir
2010/4/19 John Pallister john@synchromesh.com:
+1, as they say...
++Thanks,
John :^P
On Mon, Apr 19, 2010 at 12:42 AM, Daniel Gackle danielgackle@gmail.com wrote:
For those of us who are curious, could you talk a bit about the work you did on the compiler? Thanks Vladimir, Daniel
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
On Mon, Apr 19, 2010 at 11:03 AM, Vladimir Sedach vsedach@gmail.com wrote:
This work was removing the last of the old-style hacks from the compiler to clearly separate PS into three parts: the compiler itself, the special forms code, and the printer. This reduces code size and dependencies significantly, but the ultimate goal (which has mostly been achieved) is to provide an intermediary S-exp representation of JavaScript code that is directly and efficiently executable as Common Lisp code.
What is the motivation for using lists as the intermediate form rather than CLOS objects? I suppose that s-expressions makes it easy to use tree-walking functions out of the box, but there seem to be disadvantages when it comes to separating syntax from semantics, e.g. addressing the 'else' form of an if via (third if-statement) vs. (if-statement-else if-statement).
I have not seen the intermediary form and I am sure you have good reasons, but it is not the direction I would have gone. Could you explain the choice perhaps with some motivating examples, to enlighten us all?
In the future I'll be moving the printer code to a separate project, which will also have a parser from JavaScript to this intermediary representation. That project will serve as a useful base for JS code transformation tools, and I am planning to write a JS->CL compiler on top.
Go, Vladimir, go! That's an ambitious project but I would love to see it happen!
Please not that there is a project with a viable javascript parser and printer already. See http://github.com/gonzojive/js-parser
I adapted the code from JWACS (Javascript With Advanced Continuations Support) into a new project for parsing javascript. The original JWACS included a pretty printer and an obfuscating printer that would obfuscate non-toplevel variables. It also had a Javascript-like grammar with a few extra syntax additions.
The syntax tree represents javascript with structures rather than lists for everything, but you should be able to avoid writing the parser yourself, at the very least.
One user-visible change I made in the latest patches is to encourage use of CL equality predicates ('==' and '===' are still there but marked as deprecated).
Vladimir
Red
2010/4/19 John Pallister john@synchromesh.com:
+1, as they say...
++Thanks,
John :^P
On Mon, Apr 19, 2010 at 12:42 AM, Daniel Gackle danielgackle@gmail.com
wrote:
For those of us who are curious, could you talk a bit about the work you
did
on the compiler? Thanks 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
What is the motivation for using lists as the intermediate form rather than CLOS objects? I suppose that s-expressions makes it easy to use tree-walking functions out of the box, but there seem to be disadvantages when it comes to separating syntax from semantics, e.g. addressing the 'else' form of an if via (third if-statement) vs. (if-statement-else if-statement). I have not seen the intermediary form and I am sure you have good reasons, but it is not the direction I would have gone. Could you explain the choice perhaps with some motivating examples, to enlighten us all?
Here's an example of what the current intermediate form looks like:
(compile-statement '(defun blep (ss x y) (when foo? (let ((pair (bar))) (unless (null pair) (destructuring-bind (a b) pair (unless (or (null a) (null b)) (let ((val (baz a b))) (unless (null val) (when (blah val) (unless (blee) t)))))))))))
=>
(JS:DEFUN BLEP (SS X Y) (JS:BLOCK (JS:IF FOO? (JS:BLOCK (JS:VAR PAIR (JS:FUNCALL BAR)) (JS:IF (JS:!== PAIR NIL) (JS:BLOCK (JS:VAR A (JS:AREF PAIR 0)) (JS:VAR B (JS:AREF PAIR 1)) (JS:IF (JS:! (JS:|||| (JS:=== A NIL) (JS:=== B NIL))) (JS:BLOCK (JS:VAR VAL (JS:FUNCALL BAZ A B)) (JS:IF (JS:!== VAL NIL) (JS:BLOCK (JS:IF (JS:FUNCALL BLAH VAL) (JS:BLOCK (JS:IF (JS:! (JS:FUNCALL BLEE)) (JS:BLOCK (JS:RETURN T)))))))))))))))
As you can see, all you need is to define some functions and macros, and the resulting code is ready to be EVALed or compiled.
Go, Vladimir, go! That's an ambitious project but I would love to see it happen! Please not that there is a project with a viable javascript parser and printer already. See http://github.com/gonzojive/js-parser I adapted the code from JWACS (Javascript With Advanced Continuations Support) into a new project for parsing javascript. The original JWACS included a pretty printer and an obfuscating printer that would obfuscate non-toplevel variables. It also had a Javascript-like grammar with a few extra syntax additions. The syntax tree represents javascript with structures rather than lists for everything, but you should be able to avoid writing the parser yourself, at the very least.
Thanks for the pointer. I didn't know you based your parser on JWACS'. I took a look at JWACS when starting, but decided to base mine on Marijn Haverbeke's parse-js (http://marijn.haverbeke.nl/parse-js/); it seemed easier to modify.
Vladimir
One user-visible change I made in the latest patches is to encourage use of CL equality predicates ('==' and '===' are still there but marked as deprecated).
Vladimir
Red
2010/4/19 John Pallister john@synchromesh.com:
+1, as they say...
++Thanks,
John :^P
On Mon, Apr 19, 2010 at 12:42 AM, Daniel Gackle danielgackle@gmail.com wrote:
For those of us who are curious, could you talk a bit about the work you did on the compiler? Thanks 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
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Very interesting. So basically, you'll still need a runtime library to execute PS code in a CL environment, but you won't need an interpreter. (This is an observation Scott made to me earlier today.) Is that correct?
It's a neat insight to have observed how close PS was to being able to make this work. That is, it's a big task, but not nearly as big as one would have thought.
I'm curious as to what you propose to do with this capability. What practical applications?
One I can think of that would get me excited is the ability to evaluate PS forms in Slime (or something like it... Pslime anybody?). Perhaps this could even be hooked into sldb for the purpose of debugging PS code in a much more friendly environment than the likes of Firebug, not least because it would be linked to PS source rather than generated JS.
Daniel
On Tue, Apr 20, 2010 at 1:04 PM, Vladimir Sedach vsedach@gmail.com wrote:
What is the motivation for using lists as the intermediate form rather
than
CLOS objects? I suppose that s-expressions makes it easy to use tree-walking functions out of the box, but there seem to be disadvantages when it comes to separating syntax from semantics, e.g. addressing the 'else' form of an if via (third if-statement) vs. (if-statement-else if-statement). I have not seen the intermediary form and I am sure you have good
reasons,
but it is not the direction I would have gone. Could you explain the
choice
perhaps with some motivating examples, to enlighten us all?
Here's an example of what the current intermediate form looks like:
(compile-statement '(defun blep (ss x y) (when foo? (let ((pair (bar))) (unless (null pair) (destructuring-bind (a b) pair (unless (or (null a) (null b)) (let ((val (baz a b))) (unless (null val) (when (blah val) (unless (blee) t)))))))))))
=>
(JS:DEFUN BLEP (SS X Y) (JS:BLOCK (JS:IF FOO? (JS:BLOCK (JS:VAR PAIR (JS:FUNCALL BAR)) (JS:IF (JS:!== PAIR NIL) (JS:BLOCK (JS:VAR A (JS:AREF PAIR 0)) (JS:VAR B (JS:AREF PAIR 1)) (JS:IF (JS:! (JS:|||| (JS:=== A NIL) (JS:=== B NIL))) (JS:BLOCK (JS:VAR VAL (JS:FUNCALL BAZ A B)) (JS:IF (JS:!== VAL NIL) (JS:BLOCK (JS:IF (JS:FUNCALL BLAH VAL) (JS:BLOCK (JS:IF (JS:! (JS:FUNCALL BLEE)) (JS:BLOCK (JS:RETURN T)))))))))))))))
As you can see, all you need is to define some functions and macros, and the resulting code is ready to be EVALed or compiled.
Go, Vladimir, go! That's an ambitious project but I would love to see it happen! Please not that there is a project with a viable javascript parser and printer already. See http://github.com/gonzojive/js-parser I adapted the code from JWACS (Javascript With Advanced Continuations Support) into a new project for parsing javascript. The original JWACS included a pretty printer and an obfuscating printer that would obfuscate non-toplevel variables. It also had a Javascript-like grammar with a few extra syntax additions. The syntax tree represents javascript with structures rather than lists
for
everything, but you should be able to avoid writing the parser yourself,
at
the very least.
Thanks for the pointer. I didn't know you based your parser on JWACS'. I took a look at JWACS when starting, but decided to base mine on Marijn Haverbeke's parse-js (http://marijn.haverbeke.nl/parse-js/); it seemed easier to modify.
Vladimir
One user-visible change I made in the latest patches is to encourage use of CL equality predicates ('==' and '===' are still there but marked as deprecated).
Vladimir
Red
2010/4/19 John Pallister john@synchromesh.com:
+1, as they say...
++Thanks,
John :^P
On Mon, Apr 19, 2010 at 12:42 AM, Daniel Gackle <
danielgackle@gmail.com>
wrote:
For those of us who are curious, could you talk a bit about the work you did on the compiler? Thanks 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
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
Ok, I'm getting crashes trying to generate JS, but the problem seems like it should be easy to fix:
This form generates an error:
(ps (setf x (* x 1000)))
while this works fine:
(ps (setf x (* 1000 x)))
On Sun, Apr 18, 2010 at 6:42 PM, Daniel Gackle danielgackle@gmail.comwrote:
I'll run a diff on our generated JS tonight and report back.
For those of us who are curious, could you talk a bit about the work you did on the compiler?
Thanks Vladimir, Daniel
On Sun, Apr 18, 2010 at 5:34 PM, Vladimir Sedach vsedach@gmail.comwrote:
Just pushed a fixed. I also did a bunch of work on the compiler; let me know if anything else breaks.
Vladimir
2010/4/16 Daniel Gackle danielgackle@gmail.com:
Good catch! I should have written: (ps (let ((abc (@ x abc))) (funcall abc))) => "var abc901 = x.abc; abc();" I gave the wrong version because we have a customized @ that plays games with symbols and keywords. But the above runs in pure PS and is still a
bug,
I would think. Daniel
On Thu, Apr 15, 2010 at 9:48 PM, Michael Compton michael.compton@littleedge.co.uk wrote:
When I run that through I get:
(ps (let ((abc (@ x :abc))) (funcall abc)))
=>
"var abc = x['abc']; abc();"
Are you maybe using an earlier version of PS?
Michael
On Wed, 2010-04-14 at 22:04 -0600, Daniel Gackle wrote:
Vladimir,
I don't think we heard back about this bug. I've got an ugly workaround for it in my code, which it would be nice to get out of there. Do you think it will be hard to fix?
Daniel
On Mon, Mar 29, 2010 at 1:47 PM, Daniel Gackle danielgackle@gmail.com wrote: Just ran across this one:
(ps (let ((abc (@ x :abc))) (funcall abc))) => "var abc901 = x.abc; abc();" 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
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
Fixed. Thanks for catching that!
2010/4/19 Daniel Gackle danielgackle@gmail.com:
Ok, I'm getting crashes trying to generate JS, but the problem seems like it should be easy to fix: This form generates an error: (ps (setf x (* x 1000)))
while this works fine: (ps (setf x (* 1000 x)))
On Sun, Apr 18, 2010 at 6:42 PM, Daniel Gackle danielgackle@gmail.com wrote:
I'll run a diff on our generated JS tonight and report back. For those of us who are curious, could you talk a bit about the work you did on the compiler? Thanks Vladimir, Daniel On Sun, Apr 18, 2010 at 5:34 PM, Vladimir Sedach vsedach@gmail.com wrote:
Just pushed a fixed. I also did a bunch of work on the compiler; let me know if anything else breaks.
Vladimir
2010/4/16 Daniel Gackle danielgackle@gmail.com:
Good catch! I should have written: (ps (let ((abc (@ x abc))) (funcall abc))) => "var abc901 = x.abc; abc();" I gave the wrong version because we have a customized @ that plays games with symbols and keywords. But the above runs in pure PS and is still a bug, I would think. Daniel
On Thu, Apr 15, 2010 at 9:48 PM, Michael Compton michael.compton@littleedge.co.uk wrote:
When I run that through I get:
(ps (let ((abc (@ x :abc))) (funcall abc)))
=>
"var abc = x['abc']; abc();"
Are you maybe using an earlier version of PS?
Michael
On Wed, 2010-04-14 at 22:04 -0600, Daniel Gackle wrote:
Vladimir,
I don't think we heard back about this bug. I've got an ugly workaround for it in my code, which it would be nice to get out of there. Do you think it will be hard to fix?
Daniel
On Mon, Mar 29, 2010 at 1:47 PM, Daniel Gackle danielgackle@gmail.com wrote: Just ran across this one:
(ps (let ((abc (@ x :abc))) (funcall abc)))
=>
"var abc901 = x.abc; abc();"
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
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@common-lisp.net
-
Daniel Gackle -
John Pallister -
Michael Compton -
Red Daly -
Vladimir Sedach