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.<br>


<br>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.<br>

<br>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):<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 thing we need is the "return true".<br><br>Note also that PS is not *always* returning null; there are cases where the 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; _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 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.<br>

<br>What am I missing?<br><br>Daniel<br>