4 ms·
I see this comment all the time but it falls apart when you try and actually implement IDE features. Fundamentally, an abstract syntax tree is a canonical repr
by duped 3y ago
I see this comment all the time but it falls apart when you try and actually implement IDE features.
Fundamentally, an abstract syntax tree is a canonical representation of a program in one grammar. You cannot standardize it, because different languages have different grammars, and therefore different abstract syntax trees.
You also don't want an abstract syntax tree for IDE features at all, you want a concrete (or full) syntax tree - since ASTs are lossy and don't represent the text. Another barrier is that constructing an AST usually requires the input to be correct and complete, but most of the time, source code is incomplete and invalid. It doesn't make sense to cache the AST because it is invalidated nearly every key stroke - you want to be able to construct an AST for performing the queries you need as fast as possible in the context of invalid input.
And finally, you still need to have the source text to display anything useful to the user. So you're not saving any work by using a cached AST, you're not saving memory or disk, and you still need the plaintext anyway.
All that said, there is such a thing as the language server index format (LSIF) which LSPs can provide as a cache to clients that support LSP for performing queries on rarely invalidated source (eg dependencies) but it's not super useful for code in flight.
- owlstuffing 3y ago> different languages have different grammars Obviously. It should be understood that the idea is to have a standard AST API/format _per language_. As such it would be standard practice to provide this information as part of the parser/compiler library.