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

[Vladimir Sedach]

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 at 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 at gmail.com> wrote:
>>
>> 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
>> >
>> >
>>
>> _______________________________________________
>> 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
>
>