Protocolo de servidor de idiomas

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 del lenguaje": ^[1] características específicas del lenguaje de programación como la finalización de código , el resaltado de sintaxis y el marcado de advertencias y errores, así como rutinas de refactorización . El objetivo del protocolo es permitir que el soporte del lenguaje 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 del 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. El protocolo fue originalmente respaldado y adoptado por estas tres empresas. ^{[3] [4]} Su especificación está alojada y desarrollada en GitHub . ^[5]

Los IDE modernos proporcionan a los programadores funciones sofisticadas como finalización de código , refactorización , navegación a la definición de un símbolo , resaltado de sintaxis y marcadores de error y advertencia.

Por ejemplo, en un lenguaje de programación basado en texto, un programador podría querer cambiar el nombre de un método read. El programador podría editar manualmente los archivos de código fuente respectivos y cambiar las ocurrencias apropiadas del nombre del método antiguo por el nuevo nombre, o en su lugar usar las capacidades de refactorización de un IDE para realizar todos los cambios necesarios automáticamente. Para poder admitir este estilo de refactorización, un IDE necesita una comprensión sofisticada del lenguaje de programación en el que está escrito el código fuente del programa . Una herramienta de programación sin tal comprensión (por ejemplo, una que realice una búsqueda y reemplazo ingenua en su lugar) podría introducir errores. Al cambiar el nombre de un readmétodo, por ejemplo, la herramienta no debe reemplazar la coincidencia parcial en una variable que podría llamarse readyState, ni debe reemplazar la parte de un comentario de código que contiene la palabra "ya". Tampoco debería cambiar el nombre de una variable local read , por ejemplo, terminar alterando variables con nombres idénticos en otros ámbitos .

Los compiladores o intérpretes convencionales para un lenguaje de programación específico normalmente no pueden proporcionar estos servicios de lenguaje , porque están escritos con el objetivo de transformar el código fuente en código objeto o ejecutar inmediatamente el código. Además, los servicios de lenguaje deben poder manejar código fuente que no está bien formado , por ejemplo, porque el programador está en medio de la edición y aún no ha terminado de escribir una declaración, procedimiento u otra construcción. Además, los pequeños cambios en un archivo de código fuente que se realizan durante la escritura generalmente cambian la semántica del programa. Para proporcionar retroalimentación instantánea al usuario, la herramienta de edición debe poder evaluar muy rápidamente las consecuencias sintácticas y semánticas de una modificación específica. Por lo tanto, los compiladores e intérpretes proporcionan un candidato pobre para producir la información necesaria para que una herramienta de edición la consuma. ^[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 estaban generalmente vinculados a un IDE determinado u otro editor. 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 apuntar a las interfaces de extensión del segundo editor. ^[7]

El Protocolo de Servidor de Idioma permite desacoplar los servicios de lenguaje del editor de modo que los servicios puedan estar contenidos dentro de un servidor de lenguaje de propósito general . Cualquier editor puede heredar soporte sofisticado para muchos lenguajes diferentes haciendo uso de servidores de lenguaje existentes. De manera similar, un programador involucrado en el desarrollo de un nuevo lenguaje de programación puede hacer que los servicios para ese lenguaje estén disponibles para las herramientas de edición existentes. ^[6] El uso de servidores de lenguaje a través del Protocolo de Servidor de Idioma reduce así también la carga sobre los vendedores de herramientas de edición, porque los vendedores no necesitan desarrollar servicios de lenguaje propios para los lenguajes que el vendedor pretende soportar, siempre y cuando los servidores de lenguaje ya hayan sido implementados. El Protocolo de Servidor de Idioma también permite la distribución y desarrollo de servidores aportados por un tercero interesado, como los usuarios finales, sin la participación adicional del vendedor del compilador para el lenguaje de programación en uso o del vendedor del editor al que se está añadiendo el soporte de lenguaje. ^{[ cita requerida ]}

El 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 habilitada para el protocolo de servidor de lenguaje, la herramienta actúa como un cliente que consume los servicios de lenguaje proporcionados por un servidor de lenguaje . La herramienta puede ser un editor de texto o un IDE y los servicios de lenguaje pueden ser refactorización , finalización de código , etc.

El cliente informa al servidor sobre lo que está haciendo el usuario, por ejemplo, abrir un archivo o insertar un carácter en una posición de texto específica. El cliente también puede solicitar al servidor que realice un servicio de lenguaje, por ejemplo, formatear un rango específico en el documento de texto. El servidor responde a la solicitud de un cliente con una respuesta apropiada. Por ejemplo, la solicitud de formato se responde ya sea mediante una respuesta que transfiere el texto formateado al cliente o mediante una respuesta de error que contiene detalles sobre el error.

El protocolo de servidor de lenguaje define los mensajes que se intercambian entre el cliente y el servidor de lenguaje. Son JSON-RPC precedidos por encabezados similares a HTTP. Los mensajes pueden tener su origen en el servidor o 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 a través de 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 .

Existen 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 de servidores de lenguaje: herramientas de programación y edición inteligentes para el lenguaje de apoyo. Apress . ISBN 978-1-4842-7791-1.

• Sitio web oficial