<div>Ah yes clearer. This is similar to Vladimir's case from upthread:</div><div><br></div><div>  (defun foo ()</div><div>    (blah)</div><div>    (some-random-js-function))</div><div><br></div><div>... except that my suggestion that the compiler figure out when BLAH</div>

<div>isn't in a return position and do something like:</div><div><br></div><div>  function foo() {</div><div>      blah();</div><div>      RETURN_VALUES = null;</div><div>      return someRandomJsFunction();</div><div>

  };</div><div><br></div><div>... won't work in your case, i.e. when FOO is not a PS function.</div><div><br></div><div>But I wonder whether perfect interop from JS back into PS isn't an</div><div>overly ambitious a thing to promise. When language A and language B</div>

<div>have different calling conventions and you call B from A, it's normal</div><div>to have to follow some protocol to manually bridge the gap between</div><div>them. In this case the protocol might be: you must either return the</div>

<div>call to BLAH or clear RETURN_VALUES. Yeah this would be a pain and</div><div>easy to forget, but it is arguably a reasonable card for PS to have to</div><div>play here.</div><div><br></div><div>That being said, it's not surprising that a simple global variable</div>

<div>wouldn't do the trick in every case. I hope we can come up with</div><div>something that does.</div><div><br></div><div>But let's not forget that the current implementation is even more</div><div>broken. It doesn't do the right thing even if BLAH is in a return</div>

<div>position - so *none* of the cases we're talking about actually work</div><div>right now.</div><div><br></div><div>Daniel</div><div><br></div><br><div class="gmail_quote">On Wed, Aug 29, 2012 at 10:16 AM, Red Daly <span dir="ltr"><<a href="mailto:reddaly@gmail.com" target="_blank">reddaly@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi Daniel,</p><p dir="ltr">I'm glad to be part of the discussion :)</p>
<div class="gmail_quote"><div class="im">On Aug 28, 2012 8:53 PM, "Daniel Gackle" <<a href="mailto:danielgackle@gmail.com" target="_blank">danielgackle@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>Hi Red,</div><div><br></div><div>I was hoping you'd chime in. I'll see your scenario 3 and raise you a</div><div>3a and a 3b:</div><div><br></div><div>Scenario 3a: A non-Parenscript function that calls a mv-returning</div>






<div>             Parenscript function but only needs its first return value;</div><div><br></div><div>Scenario 3b: A non-Parenscript function that calls a mv-returning</div><div>             Parenscript function and needs all its return values.</div>






<div><br></div><div>3a works fine as long as the MV implementation is careful to use a</div><div>normal JS return to pass the first return value back to the caller.</div><div>That's true both of what PS does today and of the global-var proposal.</div>






<div><br></div><div>As for 3b (the scenario, not the hacker!), seems to me this can't work</div><div>at all and there's no need to support it. If you're a non-PS function</div><div>then by definition you can't use PS's MULTIPLE-VALUE-BIND to access</div>






<div>the additional return values because the MV construct only exists in</div><div>PS. I suppose if you really wanted to you could manually write JS to</div><div>do whatever PS does to supply those values to the caller, but then</div>






<div>you're not really a non-PS function anymore, so much as a</div><div>manually-compiled PS function.</div><div><br></div><div>Daniel</div></blockquote><div><br></div></div><div>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.</div>


<div><br></div><div>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.</div>


<div><br></div><div>Here's some code to illustrait the point:</div><div><br></div><div>(defun ps-foo ()</div><div>  (multiple-value-bind (a b) (bar)</div><div>     (+ a b)))</div><div><br></div><div>(defun ps-fn-returns-mv ()</div>


<div>  (values 1 2))</div><div><div><br>function barWorks() {</div><div>  return psFnReturnsMv();</div><div>}</div></div><div><br></div><div><div>function barBreaks() {</div><div>  psFnReturnsMv(); // global variables for MV returning get set up and linger</div>


<div>  // return a single value: 42</div><div>  return 42;</div><div>}</div></div><div><br></div><div>Let's assume the two Parenscript functions translate into something like this:</div><div><br></div><div>var RETURN_VALUES = null;</div>


<div>var MV_CALL = false;</div><div>... other global variables related to multiple values</div><div><br></div><div>function psFoo() {</div><div>  // global variable stuff</div><div>  MV_CALL = true;</div><div>  RETURN_VALUES = null;</div>


<div>  </div><div>  var a = bar();</div><div>  MV_CALL = false;</div><div>  var b = RETURN_VALUES ? RETURN_VALUES[0] : undefined;</div><div>  return a + b;</div><div>}</div><div><br></div><div>function psFnReturnsMv() {</div>


<div>  if (MV_CALL)</div><div>    RETURN_VALUES = [ 2 ];</div><div>  return 1;</div><div>}</div><div><br></div><div><br>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.</div>


<div><br></div><div>I hope this makes sense.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- Red</div></font></span><div><div class="h5"><div> </div></div></div></div></blockquote></div>