API para el desarrollo de servidores de lenguajes de modelado usando LSP

Abstract

El protocolo LSP, acrónimo de Language Server Protocol, es un protocolo de comunicación usado entre un editor y un servidor que proporciona la inteligencia del lenguaje que permite integrar funciones tales como autocompletado de código, definiciones go-to, búsqueda de referencias, y demás del estilo en el editor. Este protocolo ha sido, sin embargo, definido para ser utilizado con lenguajes de programación en formato texto: Java, C++, C#, Typescript, Python, etc., dejando a aquellos lenguajes gráficos de programación, como por ejemplo los lenguajes de modelado gráficos, en un estado incierto: ¿es posible utilizar este protocolo con lenguajes visuales de programación? En el contexto de los lenguajes visuales de programación, ¿qué se espera de un editor de lenguajes gráficos? ¿Qué partes tiene? ¿Cómo de diferente es un editor gráfico de uno orientado a lenguajes de tipo texto? A diferencia de un editor de texto en el que el usuario tiene, digamos, la total libertad de elegir la forma y el cómo quiere hacer algo (por ejemplo, en Java, utilizar un bucle for en lugar de un bucle while), un editor de lenguajes gráficos cuenta con un canvas o lienzo en el que dispondremos elementos presentes en una paleta, la cual contiene una serie de elementos ya predefinidos. Es decir, si está predefinido que una asociación se representa mediante una flecha y que una instancia de una clase lo hace por medio de una caja, nuestra paleta contendrá flechas y cajas (si quisiéramos representar una instancia por medio de un círculo esto no sería posible). ¿Es posible abstraer las características de los lenguajes de modelado gráficos de forma que puedan integrarse con el protocolo LSP? La pregunta tiene una respuesta afirmativa y pasa por la serialización del lenguaje gráfico hacía un lenguaje intermedio en formato texto que nos permita utilizar el protocolo tal y como está definido. Una vez disponemos de este lenguaje en formato texto es posible comunicar editor y servidor mediante el protocolo LSP como si de un lenguaje estándar se tratase. Por su parte en el servidor de lenguaje tenemos que tener en cuenta una característica inherente a todos los lenguajes de modelado: validación de modelos. Cualquier modelo que se precie debe estar acorde a unas restricciones definidas por su metamodelo para poder considerarlo un modelo bien formado. No existe, sin embargo, una implementación actual de un servidor de lenguaje que realice tal tarea para el protocolo LSP y éste será nuestro principal cometido. Nuestro servidor de lenguaje se encarga de recibir mensajes desde el cliente, procesarlos y facilitar una respuesta. Desgranando las características inherentes a nuestro servidor de lenguaje, observamos que necesitamos de una herramienta, una API que se encargue, primero, de la deserialización del lenguaje de intercambio que nos permita disponer de una representación idéntica del modelo a la que existe en la parte cliente, y, segundo, de su posterior validación. Una vez validado el modelo facilita el resultado de la validación al servidor que es el encargado de hacerlo llegar al cliente conforme a la especificación del protocolo.