| 01:57 | <ljharb> | bakkot: 2489, squashed or separate? |
| 02:13 | <bakkot> | one commit is good I think |
| 02:26 | <ljharb> | kk |
| 02:53 | <bakkot> | ljharb: hang on, just noticed a typo |
| 02:53 | <jmdyck> | Type(x) is T can be replaced with x is a T |
| 02:54 | <jmdyck> | the one on line 955? |
| 02:54 | <ljharb> | Why is prose an improvement over an AO? |
| 02:55 | <bakkot> | ok fixed |
| 02:55 | <bakkot> | jmdyck: #2489 doesn't touch line 955; which typo are you referring to? |
| 02:57 | <jmdyck> | <dfn id="integral-number"variants="integral Numbers"> missing space before "variants" |
| 02:58 | <jmdyck> | (#2492) |
| 02:58 | <bakkot> | ah, whoops, that landed |
| 03:16 | <jmdyck> | ljharb: One advantage of the x is a T form is that it can be more precise, e.g. x is a declarative Environment Record or x is a function object or x is an Object with a [[Foo]] internal slot |
| 03:18 | <ljharb> | How can that be more precise than an AO that has the same semantics? We can make AOs that are more precise than Type() is - that’s not an argument for inline prose, just an argument for “better than Type” |
| 03:22 | <jmdyck> | Currently, we can say x is a Record or x is an Environment Record or x is a declarative Environment Record or x is a function Environment Record and they can all be true. Even if you create a "better than Type" AO, it's still only going to return one thing for x, so it's only going to be equivalent to one of those four. |
| 03:25 | <jmdyck> | And what could a better-than-Type AO return that would give it the precision of x is an Object with a [[Foo]] internal slot? |
| 17:09 | <ljharb> | We already have that one - RequireInternalSlot(x, [[Foo]]) |
| 17:09 | <ljharb> | i'd expect an IsEnvironmentRecord AO for the other examples |
| 17:21 | <bakkot> | I would much prefer to stick with either Type or x is an Environment Record over introducing an IsEnvironmentRecord AO |
| 17:35 | <shu> | i agree with that |
| 17:35 | <shu> | seems like churn for sake of churn |
| 17:47 | <jmdyck> | So if x is a function Environment Record, IsEnvironmentRecord(x) would be true, but again, that only addresses one 'level' of precision. If I want to know if x is a declarative ER or a function ER, IsEnvironmentRecord(x) doesn't help. |
| 20:47 | <shu> | bakkot: thoughts on of "When applied to extended mathematical values, the operators refer to the usual mathematical operations over the extended real numbers; indeterminate forms are undefined and their use in this specification should be considered an editorial error." ? |
| 20:54 | <bakkot> | shu: WFM |
| 20:57 | <jmdyck> | (nm, i wasn't asked) |
| 21:03 | <shu> | jmdyck: happy to hear your thoughts too! |
| 21:03 | <jmdyck> | Thanks! It's unclear what "indeterminate forms" means. |
| 21:04 | <shu> | i was using the term from analysis: https://en.wikipedia.org/wiki/Indeterminate_form |
| 21:05 | <shu> | we could also explicitly enumerate the forms that matter here: infty/infty, 0 * infty, infty - infty (or infty + -infty) |
| 21:06 | <shu> | or we can omit that clause altogether, indeterminate forms are usually undefined, i felt like it's useful to call out that the extension of arithmetic to extended reals is only partial |
| 21:08 | <bakkot> | I definitely would like it to be called out one way or another |
| 21:09 | <bakkot> | I'm fine with the current wording. would also be fine with explicitly enumerating the forbidden forms |
| 21:11 | <jmdyck> | Is this arising from a PR? I forget. |
| 21:13 | <shu> | yes, from https://github.com/tc39/ecma262/pull/2493 |
| 21:13 | <jmdyck> | right, just landed there myself |