That makes sense. I just pushed a patch; let me know if that breaks anything.
Vladimir 2009/12/3 Daniel Gackle <[email protected]>: > 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 > [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
