[parenscript-devel] Should implicit return in PS mean always explicitly returning null in JS?

[Vladimir Sedach]

I pushed a fix for this.

2010/1/4 Daniel Gackle <danielgackle at 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 at 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 at 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 at common-lisp.net
>> > http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>> >
>> >
>>
>> _______________________________________________
>> parenscript-devel mailing list
>> parenscript-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
>
> _______________________________________________
> parenscript-devel mailing list
> parenscript-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
>
>