Throw a parser error to disambiguate numeric literals followed by .(op) #11529
Conversation
jakebolewski
added
needs decision
| @@ -280,7 +280,7 @@ | |||
| (if (eqv? (peek-char port) #\.) | |||
| (begin (read-char port) | |||
| (if (dot-opchar? (peek-char port)) | |||
| (io.ungetc port #\.) | |||
| (error "add disambiguating space between numeric literal and inflix dot operator") | |||
jakebolewski
force-pushed
the
jcb/parseerr10920
branch
from
1aa45b0 to
092dbd6
Compare
… operators This *breaking* change throws a parser error asking the user to disambiguate the parsing of a numeric literal and dot operator with no whitespace in between. We are consistent in how this is handled (always favor the operator in parsing with no disambiguating whitespace), but there was popular support that this should be special cased as it it quite hard to track these subtle syntax errors down. Closes #10920
|
I feel like it might be better to require at least one digit after a decimal point. I've always found the |
|
I was curious how annoying this change would be as it has often been brought up. After trying it, I like our current behavior better as I feel the rule is much simpler and more generic, precedence in the parser is always given to the operator when parsing an identifier / number followed by an operator. Throwing an error here seems wrong when that is the generic rule. I also agree that the best change would be to require at least one digit after the decimal point. @stevengj thought that idea was too drastic. |
|
Throwing an error here also means things like [1,2,3:4...] no longer work without being disambiguated. You have no idea if |
|
I'm going to chalk this up to a failed experiment, now that I have a better understanding of the edge cases. If we want to move to requiring a digit after a decimal point to delimit floating point literals (a huge breaking change) #10920 could be better addressed. As this is not going to happen I feel we should preserve the behavior we have now. |
Why not? It should at least be considered, or has that already come and gone? |
|
Changes Unknown when pulling 092dbd6 on jcb/parseerr10920 into ** on master**. |
This breaking change throws a parser error asking the user to
disambiguate the parsing of a numeric literal and dot operator with no
whitespace in between. We are consistent in how this is handled (always
favor the operator in parsing with no disambiguating whitespace), but
there was popular support that this should be special cased as it it
quite hard to track these subtle syntax errors down.
Closes #10920