[parenscript-devel] A simpler way to do multiple value return? (Was: PS test failures in 7be9b45)

[Daniel Gackle]

Ah yes clearer. This is similar to Vladimir's case from upthread:

  (defun foo ()
    (blah)
    (some-random-js-function))

... except that my suggestion that the compiler figure out when BLAH
isn't in a return position and do something like:

  function foo() {
      blah();
      RETURN_VALUES = null;
      return someRandomJsFunction();
  };

... won't work in your case, i.e. when FOO is not a PS function.

But I wonder whether perfect interop from JS back into PS isn't an
overly ambitious a thing to promise. When language A and language B
have different calling conventions and you call B from A, it's normal
to have to follow some protocol to manually bridge the gap between
them. In this case the protocol might be: you must either return the
call to BLAH or clear RETURN_VALUES. Yeah this would be a pain and
easy to forget, but it is arguably a reasonable card for PS to have to
play here.

That being said, it's not surprising that a simple global variable
wouldn't do the trick in every case. I hope we can come up with
something that does.

But let's not forget that the current implementation is even more
broken. It doesn't do the right thing even if BLAH is in a return
position - so *none* of the cases we're talking about actually work
right now.

Daniel


On Wed, Aug 29, 2012 at 10:16 AM, Red Daly <reddaly at gmail.com> wrote:

> Hi Daniel,
>
> I'm glad to be part of the discussion :)
> On Aug 28, 2012 8:53 PM, "Daniel Gackle" <danielgackle at gmail.com> wrote:
>
>> Hi Red,
>>
>> I was hoping you'd chime in. I'll see your scenario 3 and raise you a
>> 3a and a 3b:
>>
>> Scenario 3a: A non-Parenscript function that calls a mv-returning
>>              Parenscript function but only needs its first return value;
>>
>> Scenario 3b: A non-Parenscript function that calls a mv-returning
>>              Parenscript function and needs all its return values.
>>
>> 3a works fine as long as the MV implementation is careful to use a
>> normal JS return to pass the first return value back to the caller.
>> That's true both of what PS does today and of the global-var proposal.
>>
>> As for 3b (the scenario, not the hacker!), seems to me this can't work
>> at all and there's no need to support it. If you're a non-PS function
>> then by definition you can't use PS's MULTIPLE-VALUE-BIND to access
>> the additional return values because the MV construct only exists in
>> PS. I suppose if you really wanted to you could manually write JS to
>> do whatever PS does to supply those values to the caller, but then
>> you're not really a non-PS function anymore, so much as a
>> manually-compiled PS function.
>>
>> Daniel
>>
>
> I wasn't clear in my original post.  I'm not concerned with the
> non-Parenscript function's ability to receive multiple values.  I'm
> concerned that the non-Parenscript function will interfere with the
> multiple value return.
>
> If a non-Parenscript function calls a Parenscript function that messes
> with the global variables, the non-Parenscript function could end up
> returning stuff unintentionally.  This is because the non-Parenscript
> function will not manipulate the global variables to clean up the unused
> multiple values that are returned.
>
> Here's some code to illustrait the point:
>
> (defun ps-foo ()
>   (multiple-value-bind (a b) (bar)
>      (+ a b)))
>
> (defun ps-fn-returns-mv ()
>   (values 1 2))
>
> function barWorks() {
>   return psFnReturnsMv();
> }
>
> function barBreaks() {
>   psFnReturnsMv(); // global variables for MV returning get set up and
> linger
>   // return a single value: 42
>   return 42;
> }
>
> Let's assume the two Parenscript functions translate into something like
> this:
>
> var RETURN_VALUES = null;
> var MV_CALL = false;
> ... other global variables related to multiple values
>
> function psFoo() {
>   // global variable stuff
>   MV_CALL = true;
>   RETURN_VALUES = null;
>
>   var a = bar();
>   MV_CALL = false;
>   var b = RETURN_VALUES ? RETURN_VALUES[0] : undefined;
>   return a + b;
> }
>
> function psFnReturnsMv() {
>   if (MV_CALL)
>     RETURN_VALUES = [ 2 ];
>   return 1;
> }
>
>
> When bar = barWorks, foo will return 1 + 2, as intended.  When bar =
> barBreaks, foo will incorrectly return 42 + 2 because the global variables
> were not properly cleaned up.
>
> I hope this makes sense.
>
> - Red
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/parenscript-devel/attachments/20120829/7d86b4d8/attachment.html>