Whether a return-of-conditional gets compiled as a return-of-expression or transformed into a statement with a return inside of it is decided on a heuristic basis.
It used to be based on s-exp nesting depth, but then you'd have things like return x ? foo.bar.baz[x][y] : null being turned into verbose statements.
To fix your example, I've changed the heuristic to be based on compiling into a statement first and counting how many lines that expression would span if printed. That gives better results while being simple, but there's still a couple of cases where it doesn't feel right.
Vladimir
2010/12/7 Daniel Gackle danielgackle@gmail.com:
I noticed the JS for a function like this has changed: (defun blah () (when (some-condition) (foo) (bar) (baz))) It used to give this: function blah() { if (someCondition()) { foo(); bar(); return baz(); }; }; Now it produces this: function blah() { return someCondition() ? (foo(), barr(), baz()) : null; }; I think it's worth questioning whether this deviates too far from PS's goal of readable JS. I can give examples from our codebase where this approach produces very complex composite expressions that are quite unreadable. It doesn't bother me too much, since I understand what PS is doing and can always look at the source code. But it certainly sacrifices readability/debuggability. Too far? Daniel _______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel