After refactoring the code, it turns out that the original approach was indeed workable, and there's no need to do anything more clever. I'm still amazed how much PS can do with simple top-down local transformations.
This code should compile correctly now, without any warnings.
Vladimir
On Fri, Dec 9, 2011 at 8:45 PM, Vladimir Sedach vsedach@gmail.com wrote:
I rolled back this patch to get in some of the simple bugfixes that have piled up first. There's a good solution for this problem (and a lot of the other problems with treating loops as expressions, etc.) that will make the internals of Parenscript work more like a "real" compiler, I should have time to do it in a week or two.
Vladimir
On Thu, Sep 15, 2011 at 7:41 PM, Daniel Gackle danielgackle@gmail.com wrote:
I pushed a very simple patch for this bug. It still isn't correct, because the resulting code generates a warning, but it's a lot closer to correct than not returning a return value at all. I wasn't sure how to make a correct fix, but I badly need this return value, and this can serve as an interim compromise. On a positive note, this shows how valuable the feature is! (Vladimir, when you get to this, feel free to undo my oversimplified change.)
Daniel
On Mon, Aug 29, 2011 at 11:56 AM, Daniel Gackle danielgackle@gmail.com wrote:
I thought this was working at some point, but it doesn't seem to now. FOO() returns undefined in JS, when it should return 123:
(defun bar (fn) (funcall fn))
(defun foo () (bar (lambda () (return-from foo 123))))
It seems the value stored under the name "ps-return-value" isn't actually returned:
function foo() { try { return bar(function () { throw { 'ps-block-tag' : 'foo', 'ps-return-value' : 123 }; }); } catch (err) { if (err && 'foo' === err['ps-block-tag']) { err['ps-return-value']; } else { throw err; }; }; };
parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel