3 ms·
Tooling should not depend on code text, but on language's AST.
by KptMarchewa 4y ago
Tooling should not depend on code text, but on language's AST.
- tripa 4y agoComments tending to skip on being a part of the AST make that harder.
- bobbylarrybobby 4y agoIn practice though, getting the AST from the text is a computational task in and of itself and the grammar affects the runtime of that. For instance, Rust's "turbofish" syntax, `f::<T>(args)`, is used to specify the generic type for f when calling it; this is instead of the perhaps more obvious `f<T>(args)`, which is what the definition looks like. Why the extra colons? Because parsing `f<T>(args)` in an expression position would require unbounded lookahead to determine the meaning of the left angle bracket -- is it the beginning of generics or less-than? Therefore, even though Rust could be modified to accept`f<T>(args)` as a valid syntax when calling the function, the language team decided to require the colons in order to improve worst case parser performance.
- xigoi 4y agoThis is why using the same character as a delimiter and operator is bad.
- colejohnson66 4y agoHow does C# manage to handle without the turbo fish syntax? What’s different in Rust?
- bobbylarrybobby 4y agoIt's not impossible to handle the ambiguity, it's just that you may have to look arbitrarily far ahead to resolve it. Perhaps C# simply does this. Or perhaps it limits expressions to 2^(large-ish number) bytes.
- nightski 4y agoI'm not an expert as I do not work on these tools but I don't think IDEs can rely solely on ASTs because not all code is in a compilable state. Lots of times things have to be inferred from invalid code. Jetbrains tools for example do a great job at this.