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