| 04:59 | <Bakkot> | jmdyck: rebased 2007 |
| 05:03 | <Bakkot> | also rebased my in-progress branch on top of it, https://github.com/tc39/ecma262/tree/fix-math-fix |
| 15:56 | <devsnek> | DecimalEscape :: NonZeroDigit DecimalDigits [lookahead != DecimalDigit] |
| 15:56 | <devsnek> | what does that lookahead do |
| 15:57 | <devsnek> | s/DecimalDigits/DecimalDigits?/ |
| 17:44 | <devsnek> | i think the `i` in the spec is broken |
| 17:44 | <devsnek> | in terms of the runtime semantics |
| 17:45 | <devsnek> | if you do `/x/i.test('X')` you get PatternCharacter x which does CharacterSetMatcher(['x'], false, 1) |
| 17:47 | <devsnek> | oh nvm i'm wrong |
| 18:36 | <devsnek> | > Let n be the number of elements in r's captures List. (This is the same value as 21.2.2.1's NcapturingParens.) |
| 18:36 | <devsnek> | wouldn't this be number of elements - 1 |
| 18:37 | <devsnek> | the first element is undefined and then there is an element for each capturing paren |
| 19:01 | <jmdyck> | devsnek: I think the spec has some off-by-1 errors wrt captures List |
| 19:01 | <devsnek> | yeah that's what i'm thinking too |
| 19:01 | <devsnek> | i'm not familiar enough to regex to guess what is supposed to happen in all these loops and stuff |
| 19:01 | <devsnek> | i guess i can brute force it :P |
| 19:02 | <gibson042> | attempt to start improving that: https://github.com/tc39/ecma262/pull/2112 |
| 19:03 | <devsnek> | oh wow |
| 19:03 | <devsnek> | btw i just completely rewrote regex in engine262 |
| 19:03 | <devsnek> | it mirrors the spec pretty closely |
| 19:03 | <devsnek> | if you want to check your pr |
| 19:03 | <devsnek> | well i still need to push up a few more things |
| 19:07 | <jmdyck> | e.g., consider the two calls to BackreferenceMatcher... If you have a DecimalEscape like `\1`, then you evaluate the `1` to get the Number value *1*, and pass that to the first param of BackrefMatcher. |
| 19:08 | <devsnek> | i'm not against us doing a weird offset thing by having the first element be undefined |
| 19:10 | <jmdyck> | But if you have a GroupName-escape like `\k<foo>`, ... oh, it does work, never mind. |
| 19:11 | <gibson042> | I think the fundamental trouble in this space stems from https://tc39.es/ecma262/#sec-pattern : "indexed 1 through _NcapturingParens_" |
| 19:12 | <devsnek> | `\d-a` |
| 19:12 | <devsnek> | that's ClassAtomNoDash `-` ClassAtom |
| 19:12 | <devsnek> | right |
| 19:13 | <devsnek> | actually wait could that be |
| 19:13 | <devsnek> | ClassAtomNoDash ClassAtom ClassAtomNoDash? |
| 19:13 | <devsnek> | i guess that would make more sense |
| 19:15 | <jmdyck> | "indexed 1 through _NcapturingParens_" conflicts with 6.2.1's "The elements of a list may be randomly accessed using 0-origin indices." so 6.2.1 should at least reflect that possibility. |
| 19:26 | <devsnek> | gibson042: atm there's stuff like this "If there does not exist a member a of set A such that Canonicalize(a) is cc, return failure" |
| 19:26 | <devsnek> | what if the evaluation semantics were changed so that the sets were pre-canonicalized |
| 20:02 | <gibson042> | like what I'm already doing with _WordCharacters_, or something more? |
| 20:03 | <devsnek> | every pattern evaluator that returns characters would have to call Canonicalize on them |
| 20:04 | <devsnek> | like rn CharacterEscape returns CharacterValue of CharacterEscape |
| 20:05 | <devsnek> | so then it would return Canonicalize(CharacterValue of CharacterEscape) |
| 20:11 | <gibson042> | CharacterSetMatcher appears to be the only place for that, at least if my PR is merged |
| 20:28 | <gibson042> | so I think it would be something in that operation like "1. Let _C_ be the CharSet that contains Canonicalize(_a_) if and only if _A_ contains _a_." and then subsequent use of _C_ rather than _A_. |
| 20:44 | <gibson042> | I found a suspected off-by-one error at https://tc39.es/ecma262/#sec-atomescape . Evaluation of AtomEscape :: `k` GroupName invokes BackreferenceMatcher with 0-indexed _parenIndex_ rather than 1-indexed _parenIndex_ + 1 |
| 21:22 | <jmdyck> | gibson042: No, I thought that too (see above), but _parenIndex_ is 1-indexed. I.e. the first (leftmost) group gets a _parenIndex_ of 1 |
| 21:25 | <jmdyck> | because the GroupSpecifier that step 1 finds is *within* a group, so the leftmost GroupSpecifier still has one left-capturing paren to its left. |
| 21:32 | <gibson042> | I don't think that's right, AtomEscape :: `k` GroupName looks like `\k<foo>`—there may not *be* enclosing parentheses |
| 21:33 | <jmdyck> | parentheses around `\k<foo>` don't matter |
| 21:34 | <gibson042> | ah, I see |
| 21:34 | <jmdyck> | step 1 looks for a GroupSpecifier, which necessarily occurs within parens |
| 21:35 | <jmdyck> | specifically a left-cap paren to its immediate left |
| 21:37 | <gibson042> | yep |
| 21:37 | <jmdyck> | Might be worth a Note. |
| 21:38 | <gibson042> | I was thinking an assertion, but I'm not sure if it would be better in that evaluation or in BackreferenceMatcher |
| 21:39 | <jmdyck> | You could certainly assert that parenIndex >= 1 (in either spot), but that doesn't help explain why it's true. |
| 21:41 | <gibson042> | but it does head off the mistaken assumption |
| 21:47 | <jmdyck> | Maybe, if you put it right after the "Let parenIndex be...". If you put it in BackrefMatcher, it's still pretty easy to think that `k GroupName` fails to satisfy the assertion. |
| 21:49 | <jmdyck> | Maybe best would be a Note in `k GroupName` and an assertion in BackrefMatcher. |
| 22:44 | <gibson042> | jmdyck: https://github.com/tc39/ecma262/pull/2112/commits/6c45aff421737171d858e6361134ad5467506a06 |
| 23:38 | <devsnek> | Bakkot: what did i do wrong https://gc.gy/64289291.png |
| 23:46 | <Bakkot> | devsnek: the linter does not expect method names to have underscores |
| 23:46 | <Bakkot> | I'll fix it before we land this |
| 23:47 | <devsnek> | aight |
| 23:47 | <devsnek> | ugh idk how to deal with https://tc39.es/ecma262/#step-json-parse-parse |
| 23:48 | <devsnek> | maybe a grammar parameter? |
| 23:56 | <devsnek> | very pretty https://twitter.com/GinoRaidy/status/1290684214673846273 |
| 23:56 | <devsnek> | oops |
| 23:56 | <devsnek> | https://gc.gy/64290364.png |
| 23:56 | <devsnek> | stupid clipboard |
| 23:56 | <devsnek> | please disregard above association between "very pretty" and twitter link |
| 23:56 | <jmdyck> | devsnek: you mean how to deal with the extended PropertyDefinitionEvaluation semantics thing? |
| 23:57 | <devsnek> | yeah |
