Jump to content

Language Server Protocol

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by C. A. Russell (talk | contribs) at 01:18, 23 February 2017 (First pass at an article with just enough detail and external links to make it not qualify as a stub.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

The Language Server Protocol is an open JSON-RPC-based protocol for use between text editors or integrated development environments and servers that enable programming language-specific features. The Language Server Protocol was originally developed for Visual Studio Code and is now an open standard. On 2016 June 27, Microsoft announced a collaboration with Red Hat and Codenvy on the standard's specification.[1][2] The goal of the protocol is to allow programming language support to be decoupled and even distributed independently of any given editor or IDE.

For example, many integrated development environments (IDEs) allow for a form of code refactoring whereby the programmer renames a subroutine. With text-based programming languages, the programmer can either hand-edit the files to change the appropriate occurrences of the old name into the new name, or he or she can use the IDE's refactoring tools to make the change automatically. Refactoring tools that aim for correctness are generally reliant on a sophisticated understanding of the program's source language, because such an understanding is necessary to avoid the mistakes that a simple search and replace tool would otherwise introduce. Typically, these "language services" cannot be driven by the standard compilers for the language, because the compilers are written for the objective of either turning the source language into object code or running the code directly. Such compilers lack the special-purpose features required of editing tools, such as dealing with code that is not well-formed, e.g., because the programmer is not finished typing the current statement, procedure, or other construct, and so it is not in a "finished" state ready for consumption by the compiler.[3]

Historically, these language services have generally been tied to a given IDE or other editor and implemented by targeting a specific tool's extension APIs. To make use of the service for another editor in the easiest case has would require modifying the service's open source code to adapt it for the new editor.

By decoupling these language services from the program editor and defining a standard protocol, any editor can "inherit" mature support for many different languages by making use of existing servers. This reduces the burden on new and existing tool vendors, because those vendors need not develop language services of their own for the languages that the vendor intends to support if such a server already exists for the language. Such servers can be developed and maintained by the vendor, but they can also be developed by compiler authors or any interested third-party.

References

  1. ^ "Common Language Server Protocol". 27 June 2016. Retrieved 22 February 2017.
  2. ^ "Red Hat, Codenvy and Microsoft Collaborate on Language Server Protocol". 27 June 2016. Retrieved 22 February 2017.}}
  3. ^ "Anders Hejsberg on Modern Compiler Construction". 12 May 2016. Retrieved 22 February 2017.