< I just pushed a patch; let me know if that breaks anything. >
Thanks for this patch. It has the astonishing effect of reducing our total JS size by almost 10K, so we're obviously very pleased with the change.
We did find one breakage, involving inappropriate fall-through in switch statements:
(defun blah () (case foo (123 (when (bar) t)) (345 (blah))))
=>
function blah() { switch (foo) { case 123: if (bar()) { return true; }; case 345: return blah(); }; };
Clearly, there needs to be a "return null" in the case that bar() is false, to prevent the bug of falling into case 345 inappropriately.
Thanks again, Daniel
On Sat, Jan 2, 2010 at 2:39 PM, Vladimir Sedach vsedach@gmail.com wrote:
That makes sense. I just pushed a patch; let me know if that breaks anything.
Vladimir
2009/12/3 Daniel Gackle danielgackle@gmail.com:
I've now had a chance to systematically look at how our code fares under PS's implicit return. Thanks to Scott for being the guinea pig for the
rest
of us. I like it! I do have a few questions/issues. I'll send them in separate emails, I guess.
PS now tries to insert a default "return null;" statement in functions
that
would formerly have returned nothing, i.e. whose return values would have been undefined. I am not convinced that this buys us much. We've always treated NULL and UNDEFINED as conveying the same information when
returning
from a function. I recognize not everyone would share this
interpretation.
The trouble with explicit "return null" is that you end up with things
like
the following example taken from our code (stripped-down for brevity):
(defun blep (ss x y) (when foo? (awhen (bar) (destructuring-bind (c r) it (when (!null c r) (awhen (baz) (when (blah it) (unless (blee) t))))))))
=>
function blep(ss, x, y) { if (foowhat) { var it = bar(); if (it != null && it !== false) { var c = it[0]; var r = it[1]; if (c != null && r != null) { var it27537 = baz(); if (it27537 != null && it27537 !== false) { if (blah(it27537)) { if (!blee()) { return true; } else { return null; }; } else { return null; }; } else { return null; }; } else { return null; }; } else { return null; }; } else { return null; }; };
I wish PS would avoid generating all those "return null"s when the only thing we need is the "return true".
Note also that PS is not *always* returning null; there are cases where
the
old undefined behavior still exists:
(ps (defun foo () (dolist (a b) (blah a)))) => "function foo() { for (var a = null, _js_idx27540 = 0; _js_idx27540 < b.length; _js_idx27540 += 1) { a = b[_js_idx27540]; blah(a); }; };"
Personally, I think this is fine and would rather see all functions
behave
this way. That is, if I put a NIL in a tail position in my code, I should get "return null" and otherwise no explicit return in JS. We can't factor the null vs. undefined distinction out of PS altogether; it's too
engrained
in JS. Anyway this issue is, to my mind, distinct from the implicit
return
feature as such.
What am I missing?
Daniel
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