| 04:28 | <jmdyck> | bakkot: (re tail calls) you said "instead move control back to the most recent Let result be OrdinaryCallEvaluateBody(...) step". I assume you mean the most recent "pending" OrdinaryCallEvaluateBody step. But I don't think that would work, because the first thing after that step is "Remove calleeContext from the execution context stack", which you don't want to do, because PrepareForTailCall already removed that context from the stack. |
| 04:39 | <bakkot> | jmdyck: ah, yes, good point. I'm not sure exactly where it's mean to return to, then |
| 04:39 | <bakkot> | possibly something like "return to that step, but don't do the following one because calleeContext has already been removed"? |
| 04:41 | <bakkot> | in the case that the tailcall occurs in function being invoked via [[Call]] you could return from that [[Call]], but that doesn't work if the tailcall occurs while doing [[Construct]] |
| 04:42 | <jmdyck> | My current guess is that, if fn A calls fn B in tail position, then Call(B) returns to where Call(A) would have returned to: step 7 in EvaluateCall, but it's an outer execution of EvaluateCall. |
| 04:44 | <bakkot> | That works if you're just doing calls, but doesn't work if fn A was invoked with Construct(A) rather than Call(A) |
| 04:45 | <bakkot> | it's possible that's just an oversight |
| 04:45 | <jmdyck> | Hmm |
| 04:47 | <bakkot> | I wonder what engine262 does here |
| 04:53 | <jmdyck> | It's an oversight for me. I don't think you can call it an oversight for the spec, because the spec says almost nothing about where control returns to in tail calls. |
| 04:54 | <jmdyck> | I'm going to add a comment about tail calls to 2400. |
| 05:02 | <jmdyck> | (tomorrow) |
| 05:07 | <jmdyck> | or maybe i should make it a new issue, since the solution will probably be different from the solution for the stuff that's currently in 2400. |
| 05:08 | <bakkot> | either way |
| 05:09 | <bakkot> | also tailcalls are a huge political mess which sucks huge amounts of time and energy whenever we get into it, so everyone tries to avoid the topic |
| 05:15 | <bakkot> | I wonder if I could just email Allen and get him to explain what he was thinking when he wrote all this |
| 05:16 | <bakkot> | might be worth a shot |
| 05:16 | <jmdyck> | oh that's cheating! :) |
| 05:32 | <bakkot> | I suppose he's probably busy with hopl at the moment anyway |
| 05:36 | <jmdyck> | I thought hopl was last year, but i see it was postponed. |
| 05:37 | <bakkot> | indeed |
| 05:37 | <bakkot> | he finished the paper last year, I believe, but I don't know what the status of the accompanying talk is |
| 05:37 | <bakkot> | if it were me I'd've been putting off writing the talk until about now |
| 14:24 | <jmdyck> | http://test262.report appears to be down. |
| 14:24 | <yulia> | jmdyck: yes, for a while now |
| 14:25 | <yulia> | this is the issue: https://github.com/bocoup/test262-report-issue-tracker/issues/27 |
| 14:26 | <yulia> | i took a snapshot a few days ago when it was up (it is intermittent): http://web.archive.org/web/20210603160512/https://test262.report/ |
| 14:28 | <jmdyck> | Yeah, I found the archive.org snapshot, but I think it's incomplete (or the navigation is off). |
| 14:29 | <yulia> | hmm maybe the crawler didn't grab everything... what is it missing? |
| 14:29 | <yulia> | ill make sure i catch it the next time i go to take a snapshot |
| 14:30 | <yulia> | oh i see |
| 14:30 | <yulia> | darn |
| 14:31 | <jmdyck> | E.g., if I click on "Language Syntax", I get "The Wayback Machine has not archived that URL." |
| 14:34 | <jmdyck> | And yet, if you check http://web.archive.org/web/*/https://test262.report/browse/language/* , archive.org has archived lots of pages under /language/, so I'm not sure what's going on. |
| 21:38 | <jmdyck> | bakkot: the issue turned into a PR: https://github.com/tc39/ecma262/pull/2430 |
| 22:06 | <bakkot> | sweet |