Real Iterator Semantics (please) #4
Labels
Comments
|
Yeah, I wish, but it's kind of a rule I want to keep. There's a whole rabbit-hole of wonderful things we can get into if we assume that a CoffeeScript standard library will always be loaded. If you'd like to pursue this, you should make a branch that breaks the rule all over and really goes to town with it. |
alangpierce
added a commit
to alangpierce/coffeescript
that referenced
this issue
Oct 3, 2016
…s token (jashkenas#4) This commit adds another post-processing step after normal lexing that sets the locationData on all OUTDENT tokens to be at the last character of the previous token. This does feel like a little bit of a hack. Ideally the location data would be set correctly in the first place and not in a post-processing step, but I tried that and some temporary intermediate tokens were causing problems, so I decided to set the location data once those intermediate tokens were removed. Also, having this as a separate processing step makes it more robust and isolated. This fixes the problem in decaffeinate/decaffeinate#371 . In that issue, the CoffeeScript tokens had three OUTDENT tokens in a row, and the last two overlapped with the `]`. Since at least one of those OUTDENT tokens was considered part of the function body, the function expression had an ending position just after the end of the `]`. OUTDENT tokens are sort of a weird case in the lexer anyway, since they often don't correspond to an actual location in the source code. It seems like the code in `lexer.coffee` makes an attempt at finding a good place for them, but in some cases, it has a bad result. This seems hard to avoid in the general case. For example, in this code: ```coffee [-> a] ``` There must be an OUTDENT between the `a` and the `]`, but CoffeeScript tokens have an inclusive start and end, so they must always be at least one character wide (I think). In this case, the lexer was choosing the `]` as the location, and the parser ended up generating correct location data, I believe because it ignores the outermost INDENT and OUTDENT tokens. However, with multiple OUTDENT tokens in a row, the parser ends up producing location data that is wrong. It seems to me like there isn't a solid answer to "what location do OUTDENT tokens have", since it hasn't mattered much, but for this commit, I'm defining it: they always have the location of the last character of the previous token. This should hopefully be fairly safe because tokens are still in the same order relative to each other. Also, it's worth noting that this makes the start location for OUTDENT tokens awkward. However, OUTDENT tokens are always used to mark the end of something, so their `last_line` and `last_column` values are always what matter when determining AST node bounds, so it is most important for those to be correct.
GeoffreyBooth
referenced
this issue
in GeoffreyBooth/coffeescript
Oct 26, 2016
This was referenced Feb 19, 2018
This issue was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I know it is extending the run-time semantics of the language, but I think having real iterators instead of just arrays for comprehensions would be great.
The text was updated successfully, but these errors were encountered: