Protocolo de servidor de lenguaje

El Protocolo de Servidor de Lenguaje ( LSP ) es un protocolo abierto, basado en JSON-RPC, para su uso entre editores de código fuente o entornos de desarrollo integrados (IDE) y servidores que proporcionan "herramientas de inteligencia de lenguaje": ^{[ 1 ]} características específicas del lenguaje de programación , como autocompletado de código , resaltado de sintaxis y marcado de advertencias y errores, así como rutinas de refactorización . El objetivo del protocolo es permitir que el soporte para lenguajes de programación se implemente y distribuya independientemente de cualquier editor o IDE determinado. ^{[ 2 ]} A principios de la década de 2020, LSP se convirtió rápidamente en una "norma" para los proveedores de herramientas de inteligencia de lenguaje. ^{[ 1 ]}

LSP se desarrolló originalmente para Microsoft Visual Studio Code y ahora es un estándar abierto . El 27 de junio de 2016, Microsoft anunció una colaboración con Red Hat y Codenvy para estandarizar la especificación del protocolo. ^{[ 3 ] [ 4 ]} Su especificación se aloja y desarrolla en GitHub . ^{[ 5 ]}

Los entornos de desarrollo integrados (IDE) modernos proporcionan a los programadores funciones sofisticadas como la finalización de código , la refactorización , la navegación a la definición de un símbolo , el resaltado de sintaxis y los marcadores de errores y advertencias.

Por ejemplo, en un lenguaje de programación basado en texto, un programador podría querer renombrar un método read. El programador podría editar manualmente los archivos de código fuente correspondientes y cambiar las ocurrencias apropiadas del nombre del método antiguo por el nuevo, o bien utilizar las capacidades de refactorización de un IDE para realizar automáticamente todos los cambios necesarios. Para poder admitir este estilo de refactorización, un IDE necesita un conocimiento profundo del lenguaje de programación en el que está escrito el código fuente del programa . Una herramienta de programación sin dicho conocimiento —por ejemplo, una que realice una simple búsqueda y reemplazo— podría introducir errores. Al renombrar un readmétodo, por ejemplo, la herramienta no debería reemplazar la coincidencia parcial en una variable que podría llamarse readyState, ni debería reemplazar la parte de un comentario de código que contenga la palabra "already". Tampoco debería, por ejemplo, renombrar una variable localread terminar alterando variables con el mismo nombre en otros ámbitos .

Los compiladores o intérpretes convencionales para un lenguaje de programación específico generalmente no pueden proporcionar estos servicios de lenguaje , ya que están diseñados para transformar el código fuente en código objeto o ejecutarlo inmediatamente. Además, los servicios de lenguaje deben poder manejar código fuente mal formado , por ejemplo, cuando el programador está editando y aún no ha terminado de escribir una instrucción, procedimiento u otra construcción. Asimismo, los pequeños cambios realizados en un archivo de código fuente durante la escritura suelen modificar la semántica del programa. Para proporcionar retroalimentación instantánea al usuario, la herramienta de edición debe poder evaluar rápidamente las consecuencias sintácticas y semánticas de una modificación específica. Por lo tanto, los compiladores e intérpretes no son la mejor opción para generar la información que necesita una herramienta de edición. ^{[ 6 ]}

Antes del diseño e implementación del Protocolo de Servidor de Lenguaje para el desarrollo de Visual Studio Code, la mayoría de los servicios de lenguaje generalmente estaban vinculados a un IDE u otro editor específico. En ausencia del Protocolo de Servidor de Lenguaje, los servicios de lenguaje se implementan normalmente mediante una API de extensión específica de la herramienta . Proporcionar el mismo servicio de lenguaje a otra herramienta de edición requiere un esfuerzo para adaptar el código existente de modo que el servicio pueda dirigirse a las interfaces de extensión del segundo editor. ^{[ 7 ]}

El Protocolo de Servidor de Lenguaje permite desacoplar los servicios de lenguaje del editor, de modo que estos servicios puedan estar contenidos en un servidor de lenguaje de propósito general . Cualquier editor puede heredar una compatibilidad avanzada con muchos lenguajes diferentes mediante el uso de servidores de lenguaje existentes. Del mismo modo, un programador involucrado en el desarrollo de un nuevo lenguaje de programación puede poner los servicios para ese lenguaje a disposición de las herramientas de edición existentes. ^{[ 6 ]} El uso de servidores de lenguaje a través del Protocolo de Servidor de Lenguaje también reduce la carga de trabajo de los proveedores de herramientas de edición, ya que no necesitan desarrollar sus propios servicios de lenguaje para los lenguajes que pretenden admitir, siempre que los servidores de lenguaje ya estén implementados. El Protocolo de Servidor de Lenguaje también permite la distribución y el desarrollo de servidores aportados por un tercero interesado, como los usuarios finales, sin la participación adicional del proveedor del compilador del lenguaje de programación en uso ni del proveedor del editor al que se está agregando la compatibilidad con el lenguaje.

LSP no se limita a los lenguajes de programación. Puede utilizarse para cualquier tipo de lenguaje basado en texto, como especificaciones ^{[ 8 ]} o lenguajes específicos de dominio (DSL) ^{[ 9 ]} .

Cuando un usuario edita uno o más archivos de código fuente mediante una herramienta compatible con el protocolo de servidor de lenguaje, dicha herramienta actúa como un cliente que consume los servicios de lenguaje proporcionados por el servidor . La herramienta puede ser un editor de texto o un IDE , y los servicios de lenguaje pueden incluir refactorización , autocompletado de código , etc.

El cliente informa al servidor sobre la acción del usuario, por ejemplo, abrir un archivo o insertar un carácter en una posición específica del texto. El cliente también puede solicitar al servidor que realice un servicio lingüístico, como formatear un rango específico del documento de texto. El servidor responde a la solicitud del cliente con una respuesta adecuada. Por ejemplo, la solicitud de formato se responde con una respuesta que transfiere el texto formateado al cliente o con una respuesta de error que contiene detalles sobre el problema.

El protocolo del servidor de lenguaje define los mensajes que se intercambian entre el cliente y el servidor de lenguaje. Estos mensajes son JSON-RPC precedidos de encabezados similares a los de HTTP. Los mensajes pueden originarse tanto en el servidor como en el cliente.

El protocolo no establece ninguna disposición sobre cómo se transfieren las solicitudes, respuestas y notificaciones entre el cliente y el servidor. Por ejemplo, el cliente y el servidor podrían ser componentes dentro del mismo proceso que intercambian cadenas JSON mediante llamadas a métodos. También podrían ser procesos diferentes en la misma máquina o en máquinas diferentes que se comunican a través de sockets de red .

Hay listas de implementaciones compatibles con LSP, mantenidas por la comunidad Langserver.org ^{[ 10 ]} o Microsoft. ^{[ 11 ]}

• Gunasinghe, N.; Marcus, N. (2021). Protocolo e implementación del servidor de lenguaje: soporte para herramientas de edición y programación inteligentes en el lenguaje . Apress . ISBN 978-1-4842-7791-1.

• Sitio web oficial