Esto es parte de una serie de preguntas que se centran en un proyecto llamado Proyecto de abstracción, que tiene como objetivo abstraer los conceptos utilizados en el diseño del lenguaje en forma de marco.
Aquí se puede ver otra página asociada a ella relacionada con la tipificación estructural . El metatema asociado a una consulta sobre el marco y el lugar adecuado para publicar se puede encontrar aquí .
¿Qué tan fácil debería ser usar un marco de desarrollo del lenguaje?
He escrito marcos de generación de código a gran escala que también incluyen la capacidad de enviar el resultado al compilador específico del idioma. El tema de la facilidad de uso surge de un ejemplo de marco de este tipo: CodeDOM o el Modelo de objetos de documento de código.
Es un marco escrito por Microsoft que describe estructuras de código comunes, pero generalmente dejaba mucho de lado (coacciones de expresión) y tendía a ser un poco abstracto en su representación de ciertas construcciones, a emitir francamente código incorrecto basado en lo que estaba haciendo: antes CodeDOM mal manejado que emite PrivateImplementationTypeel CodeMemberMethod, cuando el tipo usado fue una interfaz genérica. CodeDOM fue mi razón original para escribir mi primer generador de código.
Una cosa que estoy tratando de hacer, para simplificar el marco, es reducir la cantidad de trabajo que necesita para hacer algo, y centrarme en acciones versus los tipos específicos que componen esas acciones.
Aquí hay una comparación lado a lado de cómo funciona el marco que estoy escribiendo:
//Truncated...
/* *
* From a project that generates a lexer, this is the
* state->state transition character range selection logic.
* */
var nextChar = nextMethod.Parameters.Add(new TypedName("currentChar", typeof(char).GetTypeReference()));
//...
char start = rangeElement.B.Value.Start;
char end = rangeElement.B.Value.End;
/* *
* 'start' <= nextChar && nextChar <= 'end'
* */
currentExpression = start.LessThanOrEqualTo(nextChar).LogicalAnd(nextChar.LessThanOrEqualTo(end));
Versus CodeDOM:
//Truncated...
var nextChar = new CodeVariableReferenceExpression("nextChar");
//...
var start = new CodePrimitiveExpression(rangeElement.B.Value.Start);
var end = new CodePrimitiveExpression(rangeElement.B.Value.End);
currentExpression = new CodeBinaryOperatorExpression(new CodeBinaryOperatorExpression(start, CodeBinaryOperatorType.LessThanOrEqual, nextChar), CodeBinaryOperatorType.BooleanAnd, new CodeBinaryOperatorExpression(nextChar, CodeBinaryOperatorType.LessThanOrEqual, end));
El enfoque del marco son los entusiastas del lenguaje, así como aquellos interesados en generar código o aplicaciones. Dado su enfoque en la compilación, la generación de código y el desarrollo del lenguaje, ¿debería el marco centrarse en la facilidad de uso o la potencia bruta?
Mi objetivo principal es aumentar la disponibilidad de tales herramientas, por lo que aquellos interesados en el dominio no requieren mucha experiencia en el dominio de la teoría del lenguaje antes de que puedan comenzar a trabajar en sus propios proyectos centrados en el lenguaje.
Dado que soy el autor del marco, mi visión de "usabilidad" es parcial. Por lo tanto, debo preguntarle a otro si el enfoque y la meta tienen sentido para otros que no están asociados al proyecto.
fuente
Respuestas:
Es difícil construir un marco de desarrollo del lenguaje. Debe decidir qué tipo de cosas le gustaría que respaldara, luego debe decidir qué tipo de cosas sabe hacer y cómo integrarlas juntas en un todo coherente. Finalmente, ha realizado una inversión suficiente para que funcione con lenguajes reales (p. Ej., Lenguajes informáticos típicos y DSL), y en realidad hace algo útil. Me quito el sombrero por intentarlo.
Puede comparar su esfuerzo con el que comencé hace 15 años, el DMS Software Reengineering Toolkit . DMS está destinado a proporcionar análisis, análisis y transformación de código de propósito general. Dada una especificación de lenguaje explícito, analizará el código, creará AST, regenerará el código a partir de AST (prettyprint), transformará el código utilizando patrones escritos en el lenguaje de programación específico, creará tablas de símbolos, control de cómputo y flujo de datos, etc. Al agregar código personalizado, uno hace que DMS lleve a cabo una amplia variedad de efectos. (Vea las herramientas en el sitio; todas son DMS de una forma u otra).
Aquí hay un documento técnico sobre DMS como lo fue hace varios años. (Seguimos mejorando)
Si bien el DMS en sí ha sido difícil de construir, descubrimos que se necesitó una gran cantidad de ingeniería correspondiente para definir idiomas reales para DMS, incluidos IBM COBOL, C # 4.0, Java 1.7, C ++ 11 (y muchos otros).
Lo que creemos que hace (razonablemente bien): reduce el costo de construcción de herramientas en 1-2 órdenes de magnitud. Lo que esto significa es que las tareas que de otro modo podrían tomar de 1 a 10 años pueden ser contempladas por simples mortales como proyectos de 1 mes a 1 año. Lo que aún no es fácil:
Por lo tanto, hay mucho margen de mejora. Deje florecer muchas flores.
fuente
Esta pregunta puede haber sido respondida en The Mythical Man Month, la sección "Integridad conceptual". Si no, es al menos altamente relevante para su pregunta. Aunque Brooks describe la arquitectura de un sistema informático completo, el ensayo se aplica perfectamente a marcos y nuevos lenguajes.
Creo que existe una correlación positiva entre la tasa de adopción de cualquier tecnología y su integridad conceptual y facilidad de uso. Debería haber un estudio de caso de tecnologías recientes como lenguajes, marcos y sistemas operativos, para probar esta correlación, pero aún no se sabe nada.
fuente