It appears that some commit between ac408014 and b9dc8d1a (maybe 2f9fa1976a?) breaks the compilation of CASE forms in a function's tail position when some (but not all) branches in a body form contain a RETURN.
PS> (ps (defun foo () (case x ("bar" (if y (return t) nil)) ("baz" nil)))) "function foo() { switch (x) { case 'bar': if (y) { return true; }; //----------------- missing break; here case 'baz': return null; }; };"
Scott
This bug is fixed in the patch I just committed which changes the way special operators work.
In the process of changing the special operators and fixing this bug, I came to the conclusion that there is actually no way to implement a magic "expressionize" function for the compiler that will do the right thing for all forms - the necessary transformations depend both on the outer and inner special operators in different ways. I think it's possible to avoid the complexity of having a product of all possible cases for this, and even if it's not, the special operators can be grouped into only a few common classes, so things are not that bad.
Please check out the latest version of Parenscript and see if the new code breaks anything.
Vladimir
2010/10/1 sblist@me.com:
It appears that some commit between ac408014 and b9dc8d1a (maybe 2f9fa1976a?) breaks the compilation of CASE forms in a function's tail position when some (but not all) branches in a body form contain a RETURN.
PS> (ps (defun foo () (case x ("bar" (if y (return t) nil)) ("baz" nil)))) "function foo() { switch (x) { case 'bar': if (y) { return true; }; //----------------- missing break; here case 'baz': return null; }; };"
Scott
parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
Evaluating this gives an error ("The Parenscript form .. cannot be compiled into an expression"):
PS> (ps (lambda () (if baz 7 (progn (loop :repeat 100 :do (bar)) 42))))
This wasn't an issue in the previous code, which would generate:
"function () { if (baz) { return 7; } else { for (var _js1 = 0; _js1 < 100; _js1 += 1) { bar(); }; return 42; }; };"
Scott
On 2010-11-03, at 11:23 PM, Vladimir Sedach wrote:
This bug is fixed in the patch I just committed which changes the way special operators work.
In the process of changing the special operators and fixing this bug, I came to the conclusion that there is actually no way to implement a magic "expressionize" function for the compiler that will do the right thing for all forms - the necessary transformations depend both on the outer and inner special operators in different ways. I think it's possible to avoid the complexity of having a product of all possible cases for this, and even if it's not, the special operators can be grouped into only a few common classes, so things are not that bad.
Please check out the latest version of Parenscript and see if the new code breaks anything.
Vladimir
2010/10/1 sblist@me.com:
It appears that some commit between ac408014 and b9dc8d1a (maybe 2f9fa1976a?) breaks the compilation of CASE forms in a function's tail position when some (but not all) branches in a body form contain a RETURN.
PS> (ps (defun foo () (case x ("bar" (if y (return t) nil)) ("baz" nil)))) "function foo() { switch (x) { case 'bar': if (y) { return true; }; //----------------- missing break; here case 'baz': return null; }; };"
Scott
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 the bug report.
Vladimir
2010/11/4 sblist@me.com:
Evaluating this gives an error ("The Parenscript form .. cannot be compiled into an expression"):
PS> (ps (lambda () (if baz 7 (progn (loop :repeat 100 :do (bar)) 42))))
This wasn't an issue in the previous code, which would generate:
"function () { if (baz) { return 7; } else { for (var _js1 = 0; _js1 < 100; _js1 += 1) { bar(); }; return 42; }; };"
Scott
On 2010-11-03, at 11:23 PM, Vladimir Sedach wrote:
This bug is fixed in the patch I just committed which changes the way special operators work.
In the process of changing the special operators and fixing this bug, I came to the conclusion that there is actually no way to implement a magic "expressionize" function for the compiler that will do the right thing for all forms - the necessary transformations depend both on the outer and inner special operators in different ways. I think it's possible to avoid the complexity of having a product of all possible cases for this, and even if it's not, the special operators can be grouped into only a few common classes, so things are not that bad.
Please check out the latest version of Parenscript and see if the new code breaks anything.
Vladimir
2010/10/1 sblist@me.com:
It appears that some commit between ac408014 and b9dc8d1a (maybe 2f9fa1976a?) breaks the compilation of CASE forms in a function's tail position when some (but not all) branches in a body form contain a RETURN.
PS> (ps (defun foo () (case x ("bar" (if y (return t) nil)) ("baz" nil)))) "function foo() { switch (x) { case 'bar': if (y) { return true; }; //----------------- missing break; here case 'baz': return null; }; };"
Scott
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
-
sblist＠me.com -
Vladimir Sedach