I've had the pleasure of spending a bit of time recently with Don Syme during a visit from Cambridge to MS.  For those of you who don't know, he was instrumental in the specification and development of generics in the .net runtime and in C# as well, and he's also the creator of F# (a CaML port to .net).  One of the many things we discussed was the F# langauge service he is working on (which comes as a VS2005 plugin part of the F# distribution).  For those who don't know, a "language service" is a package that provides all the language specific knowledge and interactive services to visual studio.  This is distinct from the services that the Core IDE provides that is language agnostic (but which might communicate with a language service to get it's job done).  For example, the completion list UI is provided wholy by the Core IDE, but it communicates with the C# language service to determine what to display in it and how to do it's completion logic, and it is the C# langauge service that decides when and where it pops up.

The IDE provides the service that tells us when text needs to be recolorized - the language service decides how to colorize it
The IDE provides the code definition window - the language service decides what goes in it
The IDE tells us what the commands the user has invoked - the language services decides if it wants to deal with it and decides if anyone else can deal with it.
etc. etc. etc.

In order for a "language service" package to work it needs to implement several interfaces and then register itself with VS.  it doesn't take much but it's not always clear where to start.  So, Don and i were discussing the F# language service and where he wanted to go with it, and one of the issues that came up was that he was pretty unhappy since all the samples he found for implementing a language service were in C++ and he was forced out of his pretty ML land into the unpleasant, unsafe, procedural world.  I thought that for a start we could make his life nicer by providing a managed implementation that would free him from the need to worry about how he was managing his memory.

This was work that our team had done and it was pretty clear that we could help Don out.  What then occurred to us was that "hey, maybe it's not just Don who can be helped out by this!"  So over the course of a few posts i'll walk through the steps you'll need to do create your own language service.  Which interfaces to implement, how to register your package dll, how to go about creating a colorizer, and even up to registering to listen to user commands so that you can respond to the user's typing and can perform appropriate actions in response.   Maybe we can even go into how to communicate with the debugger or interact with the forms designer :)

Hopefully those of you who have a language they love (python, ruby, perl, OCaml, whatever) and woudl like to see that language fully supported in the VS IDE will now have a series of steps they can take to move toward that goal.

Any language nuts in the audience who will want to use this?