<div>Those test failures make sense now - thanks. Also, this comment</div><div>reminded me of something:</div><div><br></div><div>< the callee.caller property for functions, which multiple value return depends on ></div>
<div><br></div><div>I dislike our implementation for multiple value return. Stuffing the</div><div>values in callee.caller is complicated and doesn't feel right (I think</div><div>I may have been the one who came up with it; it was a bad idea), plus</div>
<div>it relies on one of the shakiest aspects if not of JS itself than</div><div>certainly of the JS implementations.</div><div><br></div><div>A simpler way occurred to me the other day and I'd like to know where</div>
<div>it breaks. The argument goes like this: since JS is single-threaded</div><div>and functions have to return synchronously, there can be only one</div><div>function return in play at any given time, therefore there can be only</div>
<div>one multiple-return-value list at any time, therefore why not just</div><div>store it in a global variable?</div><div><br></div><div>Say this variable is called *spillover*. Then this:</div><div><br></div><div> (defun blah ()</div>
<div> (values 1 2 3))</div><div><br></div><div> (defun callblah ()</div><div> (multiple-value-bind (a b c) (blah)</div><div> (+ a b c)))</div><div><br></div><div>...might compile to:</div><div><br></div><div>
function blah() {</div>
<div> SPILLOVER = [2, 3];</div><div> return 1;</div><div> };</div><div> function callblah() {</div><div> var a = blah();</div><div> var b = SPILLOVER[1];</div><div> var c = SPILLOVER[2];</div><div>
return a + b + c;</div><div> };</div><div><br></div><div>There might be complicating factors that would make the JS more</div><div>involved in practice, but I don't remember what they are.</div><div><br></div>
<div>
Apart from being so much simpler, this implementation has two</div><div>advantages. First, it's "morally" better in Eugenia Cheng's sense</div><div>(<a href="http://cheng.staff.shef.ac.uk/morality/morality.pdf" target="_blank">http://cheng.staff.shef.ac.uk/morality/morality.pdf</a>). The multiple</div>
<div>return values don't belong to caller or callee, but to the call</div><div>itself. Caller and callee are functions that persist across many calls</div><div>and ought not to have information about a specific call attached to</div>
<div>them. That's why PS is forced to add ugly code to save the previous</div><div>value attached to callee and restore it using a try/finally at the end.</div><div><br></div><div>Second, it would fix a known problem. PS breaks when you have an </div>
<div>interloper like FOO here:</div><div><br></div><div> (defun blah ()</div><div> (values 1 2 3))</div><div> </div><div> (defun foo ()</div><div> (blah))</div><div> </div><div> (defun bar ()</div><div> (multiple-value-bind (a b c) (foo)</div>
<div> (+ a b c)))</div><div><br></div><div>BAR should return 6, and does in CL, but in PS it returns 1, because</div><div>FOO doesn't return multiple values, so B and C are null and "1 + null + null"</div>
<div>is 1 in JS. But the *spillover* hack would make BAR return 6.</div><div><br></div><div>Could we get away with this, or what am I missing?</div><div><br></div><div>Daniel</div><div><br></div><br><div class="gmail_quote">
On Tue, Aug 28, 2012 at 6:00 PM, Vladimir Sedach <span dir="ltr"><<a href="mailto:vsedach@gmail.com" target="_blank">vsedach@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Daniel,<br>
<br>
Yes, those two failures in the eval test suite are expected.<br>
CL-JavaScript doesn't have the callee.caller property for functions,<br>
which multiple value return depends on. I wasn't sure where to comment<br>
those tests out, so I left them in to remind myself to add<br>
callee.caller to CL-JavaScript (I've already talked to Marijn<br>
Haverbeke about that).<br>
<br>
Thank you,<br>
Vladimir<br>
<div><div><br>
On Mon, Aug 27, 2012 at 11:58 PM, Daniel Gackle <<a href="mailto:danielgackle@gmail.com" target="_blank">danielgackle@gmail.com</a>> wrote:<br>
> I've rebased my PS LOOP extensions [1] onto the latest commit<br>
> (7be9b45) and recompiled Skysheet. The generated JS looks fine. There<br>
> was one glitch that I'll report separately along with a workaround.<br>
> Before pushing the LOOP extensions onto master, though, I want to<br>
> update any relevant PS tests. Some will fail because the LOOP output<br>
> has changed quite a bit. Unfortunately I'm also seeing failures when I<br>
> run the tests in 7be9b45, which is prior to any of these LOOP<br>
> changes. I've pasted the output below [2]. It doesn't look like these<br>
> failures are related to work in ps-loop.lisp, so I'll just ignore them<br>
> for the time being, but Vladimir can you please comment on whether you<br>
> know about them or whether there's something unexpected going on?<br>
><br>
> Daniel<br>
><br>
> [1] These are the constructs FOR..OF and MAP..TO, plus a change to<br>
> FOR..ON, that I described in my email to this list on April 11. They<br>
> are currently sitting in the "loop" branch. Rebasing them was<br>
> nontrivial because of Boris' additions to ps-loop.lisp, but it seems<br>
> to have all gone ok. Boris, if you're reading this, please look out for any<br>
> regressions once I push these changes and let us know if you notice<br>
> anything.<br>
><br>
> [2] Running output tests:<br>
> ........................................................................................................................................................................................................................................................................................................................................................................................................................................<br>
> Did 424 checks.<br>
> Pass: 424 (100%)<br>
> Skip: 0 ( 0%)<br>
> Fail: 0 ( 0%)<br>
> Running package system tests:<br>
> .........<br>
> Did 9 checks.<br>
> Pass: 9 (100%)<br>
> Skip: 0 ( 0%)<br>
> Fail: 0 ( 0%)<br>
> Running CL-JavaScript eval tests:<br>
> ...........................f...............X......................<br>
> Did 66 checks.<br>
> Pass: 64 (96%)<br>
> Skip: 0 ( 0%)<br>
> Fail: 2 ( 3%)<br>
> Failure Details:<br>
> --------------------------------<br>
> mv-return1 []:<br>
> Unexpected Error: #<cl-js:js-condition #x30200155257D><br>
> [js] TypeError: undefined has no properties...<br>
> --------------------------------<br>
> --------------------------------<br>
> dynamic-extent-function-return-values []:<br>
> (funcall (if (typep #:g36204 'structure-object) #'equalp #'equal)<br>
> #:g36204 (jsarray '(1 2 3))) was NIL..<br>
> --------------------------------<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> parenscript-devel mailing list<br>
> <a href="mailto:parenscript-devel@common-lisp.net" target="_blank">parenscript-devel@common-lisp.net</a><br>
> <a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
><br>
<br>
_______________________________________________<br>
parenscript-devel mailing list<br>
<a href="mailto:parenscript-devel@common-lisp.net" target="_blank">parenscript-devel@common-lisp.net</a><br>
<a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel</a><br>
</blockquote></div><br><div>Those test failures make sense now - thanks. Also, this comment</div><div>reminded me of something:</div><div><br></div><div>< the callee.caller property for functions, which multiple value return depends on ></div>
<div><br></div><div>I dislike our implementation for multiple value return. Stuffing the</div><div>values in callee.caller is complicated and doesn't feel right (I think</div><div>I may have been the one who came up with it; it was a bad idea), plus</div>
<div>it relies on one of the shakiest aspects if not of JS itself than</div><div>certainly of the JS implementations.</div><div><br></div><div>A simpler way occurred to me the other day and I'd like to know where</div>
<div>it breaks. The argument goes like this: since JS is single-threaded</div><div>and functions have to return synchronously, there can be only one</div><div>function return in play at any given time, therefore there can be only</div>
<div>one multiple-return-value list at any time, therefore why not just</div><div>store it in a global variable?</div><div><br></div><div>Say this variable is called *spillover*. Then this:</div><div><br></div><div> (defun blah ()</div>
<div> (values 1 2 3))</div><div><br></div><div> (defun callblah ()</div><div> (multiple-value-bind (a b c) (blah)</div><div> (+ a b c)))</div><div><br></div><div>...might compile to:</div><div><br></div><div>
function blah() {</div>
<div> SPILLOVER = [2, 3];</div><div> return 1;</div><div> };</div><div> function callblah() {</div><div> var a = blah();</div><div> var b = SPILLOVER[1];</div><div> var c = SPILLOVER[2];</div><div>
return a + b + c;</div><div> };</div><div><br></div><div>There might be complicating factors that would make the JS more</div><div>involved in practice, but I don't remember what they are.</div><div><br></div>
<div>
Apart from being so much simpler, this implementation has two</div><div>advantages. First, it's "morally" better in Eugenia Cheng's sense</div><div>(<a href="http://cheng.staff.shef.ac.uk/morality/morality.pdf" target="_blank">http://cheng.staff.shef.ac.uk/morality/morality.pdf</a>). The multiple</div>
<div>return values don't belong to caller or callee, but to the call</div><div>itself. Caller and callee are functions that persist across many calls</div><div>and ought not to have information about a specific call attached to</div>
<div>them. That's why PS is forced to add ugly code to save the previous</div><div>value and restore it using a try/finally at the end.</div><div><br></div><div>Second, it would fix a known problem. PS breaks when you introduce an</div>
<div>interloper like FOO here:</div><div><br></div><div> (defun blah ()</div><div> (values 1 2 3))</div><div> </div><div> (defun foo ()</div><div> (blah))</div><div> </div><div> (defun bar ()</div><div> (multiple-value-bind (a b c) (foo)</div>
<div> (+ a b c)))</div><div><br></div><div>BAR should return 6, and does in CL, but in PS it returns 1, because</div><div>FOO doesn't return multiple values, so B and C are null and "1 + null + null"</div>
<div>is 1 in JS. But the *spillover* hack would make BAR return 6.</div><div><br></div><div>Could we get away with this, or what am I missing?</div><div><br></div><div>Daniel</div><div><br></div>