[parenscript-devel] Should implicit return in PS mean always explicitly returning null in JS?
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
On Thu, Dec 3, 2009 at 1:41 PM, Daniel Gackle <danielgackle@gmail.com> wrote:
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; }; };
For this specific example it's more a matter of generating reasonable code. There is a better way to represent this function, even when implicitly returning null: function blep(ss, x, y) { var expr = null; 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()) { expr = true; } } } } } } return expr; }; Now if I am not mistaken, Parenscript cannot make (or fake) an expression from any old Parenscript form. In my mind this is a shortcoming of Parenscript, not something we should embrace because Javascript distinguishes between statements and expressions. If I am wrong, then I'd be glad to hear about it! If we had a 100% working parenscript-form => javascript expression implementation, then implementing implicit returning would be simpler and this code generation. I have not seen the implicit return code, but this behavior may require more extensive semantic analysis than Parenscript currently supports.
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.
For most cases it will not make any difference. If it is important to the application, you can always explicitly return ps:undefined or nil. Red
What am I missing?
Daniel
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
On Thu, Dec 3, 2009 at 1:41 PM, Daniel Gackle <danielgackle@gmail.com> wrote:
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))))))))
=>
I try to follow this conversation, but above (defun blep [...]) on my system returns : "function blep(ss, x, y) { if (foowhat) { awhen(bar(), destructuringBind(c(r), it, bangnull(c, r) ? awhen(baz(), blah(it) ? (!blee() ? true : null) : null) : null)); }; };" ; I used (ps:ps ...) I assume that is because I either run the wrong Parenscript version or
On Thu, 2009-12-03 at 17:10 -0800, Red Daly wrote: there are macros involved that I don't have. ps, it got my attention because of destructering-bind, is that a macro in the latest Parenscript release ? Thanks, Wout
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; }; };
For this specific example it's more a matter of generating reasonable code. There is a better way to represent this function, even when implicitly returning null:
function blep(ss, x, y) { var expr = null; 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()) { expr = true; } } } } } } return expr; };
Now if I am not mistaken, Parenscript cannot make (or fake) an expression from any old Parenscript form. In my mind this is a shortcoming of Parenscript, not something we should embrace because Javascript distinguishes between statements and expressions. If I am wrong, then I'd be glad to hear about it!
If we had a 100% working parenscript-form => javascript expression implementation, then implementing implicit returning would be simpler and this code generation. I have not seen the implicit return code, but this behavior may require more extensive semantic analysis than Parenscript currently supports.
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.
For most cases it will not make any difference. If it is important to the application, you can always explicitly return ps:undefined or nil.
Red
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
Hi Wout, Oops, I thought I had stripped all of the app-specific code out of that function, but I hadn't. Here's another try: (defun blep (ss x y) (when foo? (let ((pair (bar))) (unless (null pair) (destructuring-bind (a b) pair (unless (or (null a) (null b)) (let ((val (baz a b))) (unless (null val) (when (blah val) (unless (blee) t)))))))))) (The point is that this is the skeleton of an actual function from our program. It's been macroexpanded in a few places and had the names changed.) To answer your questions: (1) your PS version is prior to Vladimir's work on implicit RETURN, which is why your generated code is so different from what I posted; (2) yes, there is a PS version of DESTRUCTURING-BIND. It's not the full CL version, though. If you discover you want something it doesn't do yet, post to this list. A lot of what's missing will be fairly easy to add. (And while you're at it, check out PS's LOOP as well. It too doesn't do everything that CL's does, but it does a surprising amount.) Daniel On Fri, Dec 4, 2009 at 7:44 AM, Wout Perquin <wout.perquin@skynet.be> wrote:
On Thu, Dec 3, 2009 at 1:41 PM, Daniel Gackle <danielgackle@gmail.com> wrote:
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
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
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))))))))
=>
I try to follow this conversation, but above (defun blep [...]) on my system returns : "function blep(ss, x, y) { if (foowhat) { awhen(bar(), destructuringBind(c(r), it, bangnull(c, r) ? awhen(baz(), blah(it) ? (!blee() ? true : null) : null) : null)); }; };" ; I used (ps:ps ...) I assume that is because I either run the wrong Parenscript version or
On Thu, 2009-12-03 at 17:10 -0800, Red Daly wrote: that like there are macros involved that I don't have. ps, it got my attention because of destructering-bind, is that a macro in the latest Parenscript release ? Thanks, Wout
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; }; };
For this specific example it's more a matter of generating reasonable code. There is a better way to represent this function, even when implicitly returning null:
function blep(ss, x, y) { var expr = null; 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()) { expr = true; } } } } } } return expr; };
Now if I am not mistaken, Parenscript cannot make (or fake) an expression from any old Parenscript form. In my mind this is a shortcoming of Parenscript, not something we should embrace because Javascript distinguishes between statements and expressions. If I am wrong, then I'd be glad to hear about it!
If we had a 100% working parenscript-form => javascript expression implementation, then implementing implicit returning would be simpler and this code generation. I have not seen the implicit return code, but this behavior may require more extensive semantic analysis than Parenscript currently supports.
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.
For most cases it will not make any difference. If it is important to the application, you can always explicitly return ps:undefined or nil.
Red
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
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
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
< 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
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
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
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
2009/12/3 Daniel Gackle <danielgackle@gmail.com>: that like 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
I pushed a fix for this. 2010/1/4 Daniel Gackle <danielgackle@gmail.com>:
< 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
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
The breakage with switch is fixed, thanks. We're now seeing a few superfluous "return null"s from inside TRY blocks, though. Is there some reason why these are necessary? Here's an example translated from our code. It seems like only "return blex()" should be needed: (ps (defun xyz () (try (when (blah) (when (blee) (blex))) (:finally (foo))))) => "function xyz() { try { if (blah()) { if (blee()) { return blex(); } else { return null; }; } else { return null; }; } finally { foo(); }; };" Daniel On Wed, Jan 6, 2010 at 7:35 PM, Vladimir Sedach <vsedach@gmail.com> wrote:
I pushed a fix for this.
2010/1/4 Daniel Gackle <danielgackle@gmail.com>:
< 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
_______________________________________________ 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
That behavior is motivated by the idea that RETURN from special forms like TRY should guarantee that the return statement is actually used to transfer control, that is, to do the "right thing" in scenarios such as: (ps (defun xyz () (return (try (when (blah) (when (blee) (blex))) (:finally (foo)))) (dont-call-me))) I can't really think of when this particular case would come up in normal code, but OTOH there's a trade-off to be made with having RETURN always do the expected thing. Vladimir 2010/1/7 Daniel Gackle <danielgackle@gmail.com>:
The breakage with switch is fixed, thanks.
We're now seeing a few superfluous "return null"s from inside TRY blocks, though. Is there some reason why these are necessary? Here's an example translated from our code. It seems like only "return blex()" should be needed:
(ps (defun xyz () (try (when (blah) (when (blee) (blex))) (:finally (foo)))))
=>
"function xyz() { try { if (blah()) { if (blee()) { return blex(); } else { return null; }; } else { return null; }; } finally { foo(); }; };"
Daniel
On Wed, Jan 6, 2010 at 7:35 PM, Vladimir Sedach <vsedach@gmail.com> wrote:
I pushed a fix for this.
2010/1/4 Daniel Gackle <danielgackle@gmail.com>:
< 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
_______________________________________________ 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
_______________________________________________ parenscript-devel mailing list parenscript-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
participants (4)
-
Daniel Gackle -
Red Daly -
Vladimir Sedach -
Wout Perquin