4 ms·

> We could create a parser framework that allowed a client to get some sort of generic AST and reference graph - which would enable all the use-cases of languag

> We could create a parser framework that allowed a client to get some sort of generic AST and reference graph - which would enable all the use-cases of language servers but would also allow more use-cases in the future (e.g. IntelliJ-style inspections or language-aware diffs). I think a lot of infrastructure would be simplified if each language (or interpreter/compiler) would provide a flag or tool to convert raw syntax into some sort of s-expression (or JSON or XML if you prefer). This wouldn't be a "full AST", but just the "skeleton", enough for us to do tree traversals/transformations instead of having to lex, parse, etc.

imtringued 9y ago
It would be both simple and very slow. I don't think many people are okay with the idea of waiting several seconds on starting the compiler. At the very least you have to keep the compiler process running and you need a protocol to communicate with the compiler. It already exists and is called Language Server Protocol.
- chriswarbo 9y ago
  > It would be both simple and very slow. I don't think many people are okay with the idea of waiting several seconds on starting the compiler. Is there a specific reason you think it would be slow? Translating between text formats is pretty quick, and there's no need to do anything else that compilers normally do (e.g. building an AST; type-checking; resolving imports; optimising; generating code; etc.) > At the very least you have to keep the compiler process running and you need a protocol to communicate with the compiler. That may have a slight speed benefit, but for something as fast as parsing I think it would be over-engineering. Just pipe through stdio. > It already exists and is called Language Server Protocol. LSP is certainly interesting, although it's very new and seems rather limited. I'm mostly curious why so many languages, after choosing (perfectly reasonably) to avoid an s-expression syntax, end up "throwing the baby out with the bathwater" by providing no "backend" syntax for tooling. Some tools represent code as e.g. XML for their own purposes, but I've never seen a tool-agnostic format, or a language "endorse" one of these as an interchange format. Instead, I've seen a huge amount of effort wasted on writing and maintaining a whole bunch of bespoke parsers and pretty-printers.

imtringued 9y ago

It would be both simple and very slow. I don't think many people are okay with the idea of waiting several seconds on starting the compiler. At the very least you have to keep the compiler process running and you need a protocol to communicate with the compiler. It already exists and is called Language Server Protocol.

chriswarbo 9y ago
> It would be both simple and very slow. I don't think many people are okay with the idea of waiting several seconds on starting the compiler. Is there a specific reason you think it would be slow? Translating between text formats is pretty quick, and there's no need to do anything else that compilers normally do (e.g. building an AST; type-checking; resolving imports; optimising; generating code; etc.) > At the very least you have to keep the compiler process running and you need a protocol to communicate with the compiler. That may have a slight speed benefit, but for something as fast as parsing I think it would be over-engineering. Just pipe through stdio. > It already exists and is called Language Server Protocol. LSP is certainly interesting, although it's very new and seems rather limited. I'm mostly curious why so many languages, after choosing (perfectly reasonably) to avoid an s-expression syntax, end up "throwing the baby out with the bathwater" by providing no "backend" syntax for tooling. Some tools represent code as e.g. XML for their own purposes, but I've never seen a tool-agnostic format, or a language "endorse" one of these as an interchange format. Instead, I've seen a huge amount of effort wasted on writing and maintaining a whole bunch of bespoke parsers and pretty-printers.