I pushed a fix for this. 2010/1/4 Daniel Gackle <[email protected]>: > < 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 <[email protected]> wrote: >> >> 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 > > > _______________________________________________ > 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
