| 00:24 | <Bakkot> | yeah |
| 00:25 | <Bakkot> | currently it is very clean, it's just that the thing it does very cleanly is bad |
| 00:25 | <Bakkot> | (at least in most contexts) |
| 00:25 | <Bakkot> | it is not clear that making it less clean purely for the sake of discouraging it would be an improvement |
| 00:27 | <rkirsling> | mhm |
| 00:40 | <jmdyck> | Bakkot: I'm working on 2007, but it's slow going. |
| 00:46 | <Bakkot> | jmdyck sweet |
| 00:46 | <Bakkot> | let me know if there's anything which would help on my end |
| 00:46 | <Bakkot> | e.g. if you find there's a particular batch of errors which is impeding further progress I'd be very happy to fix those |
| 00:47 | <Bakkot> | I should probably just go ahead and fix the ones I've already identified |
| 00:47 | <jmdyck> | it needs a rebase to master, and there are merge conflicts |
| 00:47 | <jmdyck> | mostly steps-with-ids |
| 00:59 | <jmdyck> | (i had to rebase my copy of 2007, because my pipeline only targets the latest master. So that isn't impeding my progress, but when I'm done, I'm probably going to submit a PR against 2007, so that should be easier of it's up-to-date.) |
| 02:00 | <jmdyck> | And there are some choices that strike me as odd. E.g., look at SplitMatch's _q_ parameter. The preamble declares it as an integral Number, and the two call-points add some stuff to ensure that it is indeed a Number. But the SplitMatch only ever uses ℝ(_q_). So why not just say it's a mathematical param, and eliminate the conversions to and from Number? |
| 03:21 | <leobalter> | Bakkot, you've got me one of the trickiest reading of the grammar today. https://github.com/tc39/test262/issues/427#issuecomment-657937019 |
| 03:21 | <leobalter> | so please, HALP |
| 03:23 | <Bakkot> | leobalter oh man that's an old issue |
| 03:23 | <Bakkot> | I will take a look |
| 03:27 | <Bakkot> | leobalter: you say in that issue "here comes a trick: IsUnresovableReference returns true becase the base value component of V is still the Global Env Record." |
| 03:27 | <Bakkot> | should that "true" be "false"? |
| 03:34 | <leobalter> | That's a part I'm not fully sure. I formulate this question better at the last comment in the issue. |
| 03:34 | <Bakkot> | my reading of the spec is that it is false |
| 03:34 | <Bakkot> | I am writing up a comment |
| 03:34 | <leobalter> | I believe IsUnresovableReference returns false, because the Reference is set |
| 03:35 | <Bakkot> | but the short version is, your reading of the spec is correct and this is a bug in ecma-262 which never got fixed |
| 03:35 | <leobalter> | I'm so glad I decided to review that old issue |
| 03:41 | <Bakkot> | commented and opened https://github.com/tc39/ecma262/issues/2093 |
| 03:42 | <Bakkot> | leobalter yeah, thanks for catching this |
| 03:42 | <Bakkot> | there's still a bunch of spec bugs :( |
| 03:42 | <Bakkot> | but we're making some progress I think! |
| 03:42 | <leobalter> | I'll add this case to the Test262 report for the fun parts. |
| 03:43 | <leobalter> | this is not simple to fix, basically we need to catch several Runtime Evaluations and add a HasBinding check before performing PutValue |
| 03:47 | <Bakkot> | leobalter the fix proposed in the esdiscuss thread is to add an additional check for the existence of the property in SetMutableBinding |
| 03:47 | <Bakkot> | for both object and global environment records, I guess |
| 03:48 | <Bakkot> | actually just for object I guess, since the global one defers to the object one for non-lexical bindings |
| 03:49 | <leobalter> | I believe for the Object we'd need to carry on some flag to tell this binding should be there |
| 03:50 | <leobalter> | at least something before PutValue for sure |
| 03:50 | <Bakkot> | there's no way to get the reference to exist in the first place without it being there |
| 03:51 | <Bakkot> | that is to say, I don't think there's a "this binding should not be there" case to distinguish from the "this binding should be there" |
| 04:02 | <leobalter> | Bakkot: perhaps this: https://github.com/tc39/ecma262/compare/master...leobalter:2093/putvalue-strict-check?expand=1 |
| 04:02 | <leobalter> | But I need to verify what else is calling PutValue |
| 04:06 | <leobalter> | I opened a draft PR for now https://github.com/tc39/ecma262/pull/2094 |
| 04:07 | <leobalter> | This might be wrong, but so far it seems ok'ish. I need to continue checking everything that goes through PutValue tomorrow |
| 04:08 | <Bakkot> | that probably works |
| 04:08 | <Bakkot> | though, ugh, this is observable because of proxies |
| 04:14 | <Bakkot> | and the proxy can have side effects |
| 04:14 | <Bakkot> | proxies are the worst |
| 04:21 | <leobalter> | Indeed |
| 18:26 | <devsnek> | that feel when U+2028 is allowed in strings |
| 18:58 | <devsnek> | why doesn't Map.prototype.delete remove `p` from `entries` |
| 19:04 | <ljharb> | huh? |
| 19:07 | <Bakkot> | "The value empty is used as a specification device to indicate that an entry has been deleted. Actual implementations may take other actions such as physically removing the entry from internal data structures." |
| 19:09 | <jmdyck> | Map.prototype.clear says: "The existing [[MapData]] List is preserved because there may be existing Map Iterator objects that are suspended midway through iterating over that List." |
| 19:09 | <jmdyck> | maybe the same reason applies to Map.p.delete |
| 19:10 | <devsnek> | i think the clear one is about the actual identity of the list |
| 19:10 | <devsnek> | not the items within |
| 19:14 | <jmdyck> | Hm, %MapIteratorPrototype%.next extracts _m_.[[MapData]] every time it's called, so it seems like neither the identity of the List nor the 'persistence' of its entries are important |
| 19:16 | <jmdyck> | no, changed my mind. |
| 19:17 | <jmdyck> | persistence of entries means that if you 'delete' while iterating, [[MapNextIndex]] will still point to the 'next' entry |
| 19:18 | <jmdyck> | if 'delete' removed an entry from the List, then [[MapNextIndex]] would 'skip' if you delete while iterating. |
| 20:43 | <jmdyck> | Bakkot: my analysis is uncovering some other (2007-independent) problems |
| 20:44 | <Bakkot> | jmdyck I am not surprised |
| 20:44 | <Bakkot> | with numbers, or more generally? |
| 20:47 | <jmdyck> | E.g. ToInteger can return +/- infinity, but it seems to me that most callers aren't dealing with that possibility. |
| 20:49 | <Bakkot> | at a quick glance it looks like most callers immediately clamp the result with min or max, which is fine |
| 20:49 | <Bakkot> | (min and max explicitly include +/- infinity in their domain) |
| 20:50 | <Bakkot> | but I could definitely believe some don't, and it certainly should not claim to return an integral number |
| 20:51 | <jmdyck> | also, that doesn't work when you try to shift things over to mathematical values |
| 20:52 | <devsnek> | what is 2007 |
| 20:52 | <jmdyck> | PR #2007, mathematical values |
| 20:52 | <devsnek> | ah |
| 20:52 | <Bakkot> | hm, well, it works fine if we say that our mathematical values are augmented with +/- infinity, but there's is some subtlety there |
| 20:54 | <jmdyck> | "Note that the mathematical value of non-finite values is not defined", so "the mathematical value of ? ToInteger(_x_)" is typically not defined |
| 20:58 | <Bakkot> | Yeah; I'll bring that up with the other editors. Personally, given this evidence, I am inclined to say that you are allowed to take the mathematical value of infinities (but not NaN), though that may cause trouble elsewhere |
| 20:59 | <ljharb> | i would be inclined the same, pending the trouble it will probably cause elsewhere |
| 21:33 | <Bakkot> | maybe we want to introduce extended mathematical values |
| 21:33 | <Bakkot> | which is the reals and also +/- infinity |
| 21:33 | <Bakkot> | but keep this distinct from regular mathematical values |
| 21:33 | <Bakkot> | and only ever do comparisons on things in this class |
| 21:34 | <Bakkot> | (I know we do actual arithmetic in some cases and we'd probably change those.) |