syntax highlighting parsers don't need to handle this :) nor does rustfmt but yes, I agree with your general point wrt proc macros
-
-
Syntax highlighting doesn’t even need to parse the language, only lex it.
2 replies 0 retweets 0 likes -
semantic highlighting needs to parse.
1 reply 0 retweets 0 likes -
Of all the difficulties involved in doing partial parses of Rust, with error recovery, etc, unbounded lookahead is not even in the top 100.
1 reply 0 retweets 0 likes -
this isn't about some huge one-time insurmountable cost it's about drawing a line in the sand so the grammar doesn't slowly slide into something ugly
1 reply 0 retweets 1 like -
And I’m saying this is a pointless line to draw. Draw the line at, like, the lexer hack. Not this. If we had persisted with the “line in the sand” reasoning in Rust’s early days, we’d have been writing “match foo { None. => {…} }” because someone might name a variable None.
1 reply 0 retweets 1 like -
Yes, that was a mistake.
1 reply 0 retweets 5 likes -
Replying to @graydon_pub @pcwalton and
It was compounded by dozens of other "just a little more" mistakes and we are now in 2019 and nobody even knows whether it'll be possible to formalize the language in a grammar at all.
2 replies 0 retweets 5 likes -
I don’t actually think it matters very much whether the language grammar can be formalized.
1 reply 0 retweets 0 likes
Whoa, I hadn’t considered that. Great point! In other words, this problem is solvable by just introducing an upper bound on the amount of lookahead that we do that is so high nobody will hit it in practice.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.