In this example, the CREATE form is being expanded incorrectly, because the symbol A passed to it is not a reference to either of the lexical variables in scope.
(ps (let ((a 99)) (let ((a 22)) (create a 33))))
=>
"var a = 99; var a666 = 22; { a666 : 33 };"
Further to the previous bug report, I noticed that lexical variables are being renamed unnecessarily in this case:
(ps (let ((x (@ foo x))) (blah x))) => "var x2 = foo.x; blah(x2);"
Here the generated code isn't incorrect, as in the bug with CREATE, but I wonder if the two problems aren't related: in each case, PS appears to mistake a symbol reference for a lexical variable reference.
On Fri, Oct 9, 2009 at 2:00 PM, Daniel Gackle danielgackle@gmail.comwrote:
In this example, the CREATE form is being expanded incorrectly, because the symbol A passed to it is not a reference to either of the lexical variables in scope.
(ps (let ((a 99)) (let ((a 22)) (create a 33))))
=>
"var a = 99; var a666 = 22; { a666 : 33 };"
Daniel Gackle danielgackle@gmail.com writes:
Further to the previous bug report, I noticed that lexical variables are being renamed unnecessarily in this case:
(ps (let ((x (@ foo x))) (blah x))) => "var x2 = foo.x; blah(x2);"
This also works fine on my branch.
My let fixed could be merged into parenscript proper without my other changes.
This is actually due to the dumb way that LET decides whether it needs to rename a variable or not. I'm going to see if I can make it produce better code.
Vladimir
On Fri, Oct 9, 2009 at 2:46 PM, Daniel Gackle danielgackle@gmail.com wrote:
Further to the previous bug report, I noticed that lexical variables are being renamed unnecessarily in this case:
(ps (let ((x (@ foo x))) (blah x))) => "var x2 = foo.x; blah(x2);"
Here the generated code isn't incorrect, as in the bug with CREATE, but I wonder if the two problems aren't related: in each case, PS appears to mistake a symbol reference for a lexical variable reference.
On Fri, Oct 9, 2009 at 2:00 PM, Daniel Gackle danielgackle@gmail.com wrote:
In this example, the CREATE form is being expanded incorrectly, because the symbol A passed to it is not a reference to either of the lexical variables in scope.
(ps (let ((a 99)) (let ((a 22)) (create a 33))))
=>
"var a = 99; var a666 = 22; { a666 : 33 };"
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Daniel Gackle danielgackle@gmail.com writes:
In this example, the CREATE form is being expanded incorrectly, because the symbol A passed to it is not a reference to either of the lexical variables in scope.
(ps (let ((a 99)) (let ((a 22)) (create a 33))))
=>
"var a = 99; var a666 = 22; { a666 : 33 };"
This works on my branch.
Lexical renaming is implementing in a very wrong way in the main parenscript branch (by abusing symbol macros). I have introduced a js:let syntax form and perform renaming at print time instead. The implementation is significantly shorter and works for all cases.
http://git.hcoop.net/?p=clinton/parenscript.git;a=summary
Lexical renaming is implementing in a very wrong way in the main parenscript branch (by abusing symbol macros). I have introduced a js:let syntax form and perform renaming at print time instead. The implementation is significantly shorter and works for all cases.
Have you run the PS unit tests on your branch? I just cloned your repository (up to patch faa26a99e6712), and it doesn't compile, but from looking at the code it would seem your changes wouldn't handle special variables, and maybe a few other things.
I don't think there's anything wrong with using symbol-macrolet as the mechanism to implement renaming - so far I haven't been able to think of any cases where it would cause a conflict.
Another thing I want to do is to make the PS printer take as input an s-expression representation of JavaScript - I'm working on a JS parser that will produce that representation as output, and a translator from the representation to CL. Eventually I want to take the printer out of Parenscript and move it into a separate project. So I'm a little against putting in non-JS constructs into the language that the printer understands.
Vladimir
http://git.hcoop.net/?p=clinton/parenscript.git;a=summary
-- Lindsay (Carlton): nighttime baker! sounds a little iffy
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
< so far I haven't been able to think of any cases where it would cause a conflict. >
Interestingly, I just ran across such a conflict. I applied the fix in 68d111 (thanks), and discovered one thing that broke in our JS as a result. It turns out that, in this one place, we do use a symbol macro as a property name in a CREATE form. Something like this:
(ps (define-symbol-macro sym what-we-really-want))
(ps (create sym 123)) as of 68d111 => "{ sym : 123 };" but should be => "{ whatWeReallyWant : 123 };"
I can change the code to not use a symbol macro that way. But at a deeper level, it seems like if one is going to have symbol macros, they should work here.
I'm not arguing for or against any particular implementation of lexical scoping, but rather that such implementation details shouldn't percolate up to the language level.
On Tue, Oct 13, 2009 at 10:14 AM, Vladimir Sedach vsedach@gmail.com wrote:
Lexical renaming is implementing in a very wrong way in the main parenscript branch (by abusing symbol macros). I have introduced a js:let syntax form and perform renaming at print time instead. The implementation is significantly shorter and works for all cases.
Have you run the PS unit tests on your branch? I just cloned your repository (up to patch faa26a99e6712), and it doesn't compile, but from looking at the code it would seem your changes wouldn't handle special variables, and maybe a few other things.
I don't think there's anything wrong with using symbol-macrolet as the mechanism to implement renaming - so far I haven't been able to think of any cases where it would cause a conflict.
Another thing I want to do is to make the PS printer take as input an s-expression representation of JavaScript - I'm working on a JS parser that will produce that representation as output, and a translator from the representation to CL. Eventually I want to take the printer out of Parenscript and move it into a separate project. So I'm a little against putting in non-JS constructs into the language that the printer understands.
Vladimir
http://git.hcoop.net/?p=clinton/parenscript.git;a=summary
-- Lindsay (Carlton): nighttime baker! sounds a little iffy
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
Interestingly, I just ran across such a conflict. I applied the fix in 68d111 (thanks), and discovered one thing that broke in our JS as a result. It turns out that, in this one place, we do use a symbol macro as a property name in a CREATE form. Something like this:
(ps (define-symbol-macro sym what-we-really-want))
(ps (create sym 123)) as of 68d111 => "{ sym : 123 };" but should be => "{ whatWeReallyWant : 123 };"
I can change the code to not use a symbol macro that way. But at a deeper level, it seems like if one is going to have symbol macros, they should work here.
I'm not sure whether it's better to classify this as a bug in CREATE. The previous behavior was treating symbols as constants, except when they had symbol macros associated with them. There's nothing wrong with that behavior, but I'm not sure there are any other special forms that do the same thing.
Vladimir
I'm not arguing for or against any particular implementation of lexical scoping, but rather that such implementation details shouldn't percolate up to the language level.
On Tue, Oct 13, 2009 at 10:14 AM, Vladimir Sedach vsedach@gmail.com wrote:
Lexical renaming is implementing in a very wrong way in the main parenscript branch (by abusing symbol macros). I have introduced a js:let syntax form and perform renaming at print time instead. The implementation is significantly shorter and works for all cases.
Have you run the PS unit tests on your branch? I just cloned your repository (up to patch faa26a99e6712), and it doesn't compile, but from looking at the code it would seem your changes wouldn't handle special variables, and maybe a few other things.
I don't think there's anything wrong with using symbol-macrolet as the mechanism to implement renaming - so far I haven't been able to think of any cases where it would cause a conflict.
Another thing I want to do is to make the PS printer take as input an s-expression representation of JavaScript - I'm working on a JS parser that will produce that representation as output, and a translator from the representation to CL. Eventually I want to take the printer out of Parenscript and move it into a separate project. So I'm a little against putting in non-JS constructs into the language that the printer understands.
Vladimir
http://git.hcoop.net/?p=clinton/parenscript.git;a=summary
-- Lindsay (Carlton): nighttime baker! sounds a little iffy
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
Just pushed a fix. Thanks for the bug report.
The problem was that CREATE was trying to compile the keys, even though it would later treat them as constants.
Vladimir
On Fri, Oct 9, 2009 at 2:00 PM, Daniel Gackle danielgackle@gmail.com wrote:
In this example, the CREATE form is being expanded incorrectly, because the symbol A passed to it is not a reference to either of the lexical variables in scope.
(ps (let ((a 99)) (let ((a 22)) (create a 33))))
=>
"var a = 99; var a666 = 22; { a666 : 33 };"
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel@common-lisp.net
-
Clinton Ebadi -
Daniel Gackle -
Vladimir Sedach