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 <[email protected]>: > 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 > [email protected] > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel > > _______________________________________________ parenscript-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
