Out with the old, in with the new

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?

Comments (20)
  1. Steve Maine says:

    I’d love to hear about how to accomplish what you’re talking about! The unmanaged implementation is very hard to navigate. I can think of some fun side projects that might arise as a result of this information. Bring it on!

  2. Joe Duffy says:

    I’m eagerly awaiting… I’m part-way through a Scheme compiler implementation, and VS integration is certainly on the todo list…

  3. Lee says:

    This is something I would find extremely interesting! Go for it…

  4. Phil Weber says:

    Yes, how about VB6? 😉

  5. Samuel Jack says:

    I might never use this information, but I would certainly be interested to read about it. (Although strangely, the things that I read – however seemingly irrelevant at the time – have a strange habit of becoming useful later on!)

  6. Matt Ellis says:

    I’d really love to see how to talk to the debugger! I’ve got an idea for a tool window I want to write, which is somewhat similar to the watch window, but I’ve no idea how to do this. The docs describe how to write a language service, or a debugging engine, but don’t provide any information about the glue in the middle – how do you, as a toolwindow type package, get to the language service or the debug engine?

  7. Absolutely, I have at least two pseudolanguages that my team edits in VS.NET that could benefit from this.

    Will this information apply to both VS2003 and Whidbey, or just Whidbey? (FWIW, if you’re just planning on doing it for Whidbey, it would be very helpful for me if you could include at least some hints on how the process differs if you’re working with VS2003)

  8. fuz says:

    Oooo, the "scripty" languages like python and perl could be very interesting language services. For personal reasons, I’d be into that. But for task-driving-evil-business-manager mode, I have to agree with the VB6 suggestion too.

  9. Clint Miller says:

    This would be awesome! The extensibility of Visual Studio has always been somewhat intimidating with all the COM code necessary to implement an add-in. I love the idea of a managed layer over the COM interfaces.

  10. Daniel Dunbar says:

    Right on! I will be very excited to see this information. I find VS very nicely organized and end up

    using it for most project based things I do even if most of the time I am using customized tools

    to do the compiling or what have you.

    I have been using VisualPython from ActiveState for the stuff in python but have not really

    been impressed with its functioning and have debated writing my own Python language service

    but haven’t had the impetus. Some illuminating information on implementing a language

    service will probably provide that.

  11. This sounds like a great idea! Should give a nice insight of VS’s internal workings! Can’t wait to read your posts!

  12. Lorenzo says:

    Great!!! I’m just implementing a dielect of C# using Rotor as a code base, for my research program st the university. Clearly, since it is a dialect voted to improved usability on concurrency, i’d like very much a great syntax coloring!!!

  13. I’d love to have this! I have just the language(s) to use it for. 😀

  14. This is exactly what I was waiting for! I have already implemented some integration with VS for Nemerle (http://nemerle.org/blog/archive/2004/Dec-16.html), but I’m now struggling with poor documentation and lack of managed examples in VSIP for VS2005Beta1.

    Maybe I will point out a few details:

    We already have:

    – language package registering language extensions, etc.

    – colorizer (not perfect, but fast)

    – project support for building and adding new files

    What I’m looking very eagerly for are:

    – integration of language servise with debugger (for now it would be nice just to have colorizer enabled in MS CLR Debugger, to have code look nicer, but in future also other things)

    – object view, so we can dynamically add and update classes existing in typed code to the object view

    – codecompletion, which seems to be the hardest task, but nicest to have –

    it needs to bind deeply to language’s typing engine

  15. Haskell says:

    I’d like to see Haskell98 support in VS (not Haskell# or some other variant)

  16. 视频会议 says:


Comments are closed.

Skip to main content