3 ms·

I’m suggesting that it has to happen in a specific order, which it does. Regardless of the direction the tokenization process reads, the rules can’t be evaluate

by css 5y ago

I’m suggesting that it has to happen in a specific order, which it does. Regardless of the direction the tokenization process reads, the rules can’t be evaluated concurrently. > the first thing it sees looks like the start of a number Yes, because it checks if the token is a number before checking if it is a name.

tom_mellior 5y ago
Names cannot start with a decimal digit, so 0xfor can never be a name. It doesn't matter in which order the rules are checked.
- css 5y ago
  > 0xfor can never be a name But to know if a token is a name, it has to check, and that check never happens because the tokenizer yields when the number case hits. You can attach a debugger and see for yourself. > It doesn't matter in which order the rules are checked. Nowhere did I claim otherwise. The rules _do_ happen in a deterministic order, which I posted the source code for.
  - tom_mellior 5y ago
    >> It doesn't matter in which order the rules are checked. > Nowhere did I claim otherwise. You claimed otherwise when you wrote "Because the hexadecimal parsing rule [0] happens before [1] the rule that parses names [2]", and when you wrote "literals have to be evaluated before names", and when you wrote "the rules can’t be evaluated concurrently". That is, you claimed otherwise in every single one of your posts in this subthread.
    - css 5y ago
      The check whether a token is a number happens before the check whether a token is a name, as evinced by both the source code and a trivial debugger session. You are conflating the fact that there is an order to the rules with a strawman that the rules _must_ be evaluated in a specific order. All of the quotes you pulled are facts (Python checks if a token is a number before it checks if it is a name, Python checks if a token is a literal before it checks if it is a name, and the rules are not evaluated concurrently), but your strawman is making a different claim.
      - tom_mellior 5y ago
        > a strawman that the rules _must_ be evaluated in a specific order. I'm not the one who wrote "literals have to be evaluated before names". > rules are not evaluated concurrently Strawman yourself. I didn't say they were evaluated concurrently, I said that your claim that they can't be evaluated concurrently was wrong. They could be, because they are disjoint, and regardless of order only one of them can match at input starting with a '0' character. Anyway, I'm done here.

by css 5y ago

tom_mellior 5y ago

Names cannot start with a decimal digit, so 0xfor can never be a name. It doesn't matter in which order the rules are checked.

css 5y ago
> 0xfor can never be a name But to know if a token is a name, it has to check, and that check never happens because the tokenizer yields when the number case hits. You can attach a debugger and see for yourself. > It doesn't matter in which order the rules are checked. Nowhere did I claim otherwise. The rules _do_ happen in a deterministic order, which I posted the source code for.
- tom_mellior 5y ago
  >> It doesn't matter in which order the rules are checked. > Nowhere did I claim otherwise. You claimed otherwise when you wrote "Because the hexadecimal parsing rule [0] happens before [1] the rule that parses names [2]", and when you wrote "literals have to be evaluated before names", and when you wrote "the rules can’t be evaluated concurrently". That is, you claimed otherwise in every single one of your posts in this subthread.
  - css 5y ago
    The check whether a token is a number happens before the check whether a token is a name, as evinced by both the source code and a trivial debugger session. You are conflating the fact that there is an order to the rules with a strawman that the rules _must_ be evaluated in a specific order. All of the quotes you pulled are facts (Python checks if a token is a number before it checks if it is a name, Python checks if a token is a literal before it checks if it is a name, and the rules are not evaluated concurrently), but your strawman is making a different claim.
    - tom_mellior 5y ago
      > a strawman that the rules _must_ be evaluated in a specific order. I'm not the one who wrote "literals have to be evaluated before names". > rules are not evaluated concurrently Strawman yourself. I didn't say they were evaluated concurrently, I said that your claim that they can't be evaluated concurrently was wrong. They could be, because they are disjoint, and regardless of order only one of them can match at input starting with a '0' character. Anyway, I'm done here.