Anders Hejlsberg

Oddly, it isn't until this port to go now that we're switching to LSP.

We had our own precursor of LSP because LSP didn't exist when we first integrated TypeScript into Visual Studio Code.

But there were a lot of learnings from that.

So it's been an incredibly symbiotic and fulfilling experience to build these two

projects in parallel in open source.

And I think it has totally changed people's view of Microsoft in the developer ecosystem.

Sure.

It's in many ways a fairly typical compiler and in many ways not.

Pretty much every compiler has what's known as a lexer or scanner that takes text and turns it into tokens.

And then typically on top of that, you have a parser that takes the tokens, checks their sequencing, and then makes abstract syntax trees, which is a tree that you can navigate that effectively is a map of

of the source code, you know, but broken into syntactic primitives and checked that, you know, like syntactically everything is, or grammatically that everything is correct.

So those are the first two stages of the pipeline.

Then we have, well, we have one extra pass that we call the binder, which is, you know, once we have the parse trees, then we bind symbol information to them where we find all of the, all of the declarations.

up variables and whatever, and build simple tables and attach them to their functions such that we can then later look up names effectively.

And we also build in the binder, we build a control flow graph, and I can talk about what that helps us do.

And then we have the type checker, which is the largest part of our pipeline.

And that's the thing that checks.

semantically that your program is correct.

It's the thing that figures out types and checks that the types relate correctly and that you're assigning the right thing to the right thing.

And then that, you know, that you're calling something that actually exists and so forth.