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