El lenguaje de descripción del compilador (CDL) es un lenguaje de programación basado en gramáticas de afijos . Es muy similar a la notación en forma Backus-Naur (BNF). Fue diseñado para el desarrollo de compiladores . Es muy limitado en sus capacidades y flujo de control, y lo es intencionalmente. Los beneficios de estas limitaciones son dobles.
Por un lado, hacen posible el sofisticado análisis de flujo de control y datos utilizado por los optimizadores CDL2, lo que da como resultado un código extremadamente eficiente. El otro beneficio es que fomentan una convención de nomenclatura muy detallada. Esto, a su vez, conduce a programas que, en gran medida, se autodocumentan .
El lenguaje se parece un poco a Prolog (esto no es sorprendente ya que ambos lenguajes surgieron aproximadamente al mismo tiempo sin trabajar en gramáticas de afijos ). Sin embargo, a diferencia de Prolog, el flujo de control en CDL se basa de manera determinista en éxito/fracaso, es decir, no se prueban otras alternativas cuando la actual tiene éxito. Esta idea también se utiliza al analizar gramáticas de expresiones .
CDL3 es la tercera versión del lenguaje CDL, significativamente diferente de las dos versiones anteriores.
La versión original, diseñada por Cornelis HA Koster en la Universidad de Nijmegen , que surgió en 1971, tenía un concepto bastante inusual: no tenía núcleo. Una fuente de lenguaje de programación típica se traduce a instrucciones de máquina o secuencias predefinidas de esas instrucciones. Representan el núcleo, las abstracciones más básicas que admite el lenguaje dado. Estas primitivas pueden ser la suma de números, la copia de variables entre sí, etc. CDL1 carece de ese núcleo. Es responsabilidad del programador proporcionar las operaciones primitivas en una forma que luego pueda convertirse en instrucciones de máquina mediante un ensamblador o un compilador de un lenguaje tradicional. El lenguaje CDL1 en sí no tiene concepto de primitivas, ni concepto de tipos de datos aparte de la palabra de máquina (una unidad abstracta de almacenamiento, no necesariamente una palabra de máquina real como tal). Las reglas de evaluación son bastante similares a las descripciones de sintaxis de las formas Backus-Naur ; de hecho, escribir un analizador para un lenguaje descrito en BNF es bastante sencillo en CDL1.
Básicamente, el lenguaje se compone de reglas. Una regla puede tener éxito o fracasar. Una regla consta de alternativas que son secuencias de otras invocaciones de reglas. Una regla tiene éxito si cualquiera de sus alternativas tiene éxito; estos se prueban en secuencia. Una alternativa tiene éxito si todas sus invocaciones de reglas tienen éxito. El lenguaje proporciona operadores para crear bucles de evaluación sin recursividad (aunque esto no es estrictamente necesario en CDL2 ya que el optimizador logra el mismo efecto) y algunos atajos para aumentar la eficiencia de la evaluación que de otro modo sería recursiva, pero el concepto básico es el anterior. Además de la aplicación obvia en el análisis gramatical libre de contexto, CDL también es adecuado para aplicaciones de control, ya que muchas aplicaciones de control son esencialmente reglas si-entonces profundamente anidadas.
Cada regla CDL1, mientras se evalúa, puede actuar sobre datos que sean de un tipo no especificado. Idealmente, los datos no deberían cambiarse a menos que la regla sea exitosa (no hay efectos secundarios en caso de falla). Esto causa problemas ya que, aunque esta regla pueda tener éxito, la regla que la invoca aún podría fallar, en cuyo caso el cambio de datos no debería surtir efecto. Es bastante fácil (aunque requiere mucha memoria) asegurar el comportamiento anterior si todos los datos se asignan dinámicamente en una pila. Sin embargo, es bastante difícil cuando hay datos estáticos, lo que suele ser el caso. El compilador CDL2 es capaz de señalar posibles violaciones gracias al requisito de que la dirección de los parámetros (entrada, salida, entrada-salida) y el tipo de reglas (pueden fallar: prueba , predicado ; no pueden fallar: función , acción ; pueden tener un efecto secundario: predicado , acción ; no puede tener un efecto secundario: prueba , función ) debe ser especificado por el programador.
Como la evaluación de reglas se basa en llamar reglas cada vez más simples, en la parte inferior debe haber algunas reglas primitivas que hagan el trabajo real. Ahí es donde CDL1 sorprende mucho: no tiene esas primitivas. Tienes que proporcionar esas reglas tú mismo. Si necesita una adición en su programa, debe crear una regla con dos parámetros de entrada y un parámetro de salida, y su código establece que la salida será la suma de las dos entradas. El compilador CDL utiliza su código como cadenas (existen convenciones sobre cómo hacer referencia a las variables de entrada y salida) y simplemente lo emite según sea necesario. Si describe su regla de adición usando ensamblador, necesitará un ensamblador para traducir la salida del compilador CDL al código de máquina. Si describe todas las reglas primitivas (macros en terminología CDL) en Pascal o C, entonces necesita un compilador Pascal o C para ejecutarse después del compilador CDL. Esta falta de primitivas centrales puede resultar muy dolorosa cuando hay que escribir un fragmento de código, incluso para la operación de instrucción de máquina más simple. Sin embargo, por otro lado, le brinda una gran flexibilidad para implementar primitivas esotéricas y abstractas que actúan sobre objetos abstractos exóticos (la 'palabra máquina' en CDL se parece más a 'unidad de almacenamiento de datos, sin referencia al tipo de datos almacenados allí). ). Además, los grandes proyectos utilizaron bibliotecas de primitivas cuidadosamente diseñadas. Luego, estos se replicaron para cada arquitectura y sistema operativo de destino, lo que permitió la producción de código altamente eficiente para todos.
Para tener una idea del lenguaje, aquí hay un pequeño fragmento de código adaptado del manual CDL2:
ACCIÓN clasificación rápida + >desde + >hasta -p -q: menos+de+a, dividir+de+a+p+q, clasificación rápida+desde+q, clasificación rápida+p+a; +.ACCIÓN dividir + >i + >j + p> + q> -m: hacer+p+i, hacer+q+j, sumar+i+j+m, reducir a la mitad+m, (nuevamente: subir+j+p+m, bajar+i+q+m, (menos+p+q, elemento de intercambio+p+q, incr+p, decr+q, *nuevamente; menos+p+m, intercambiar artículo+p+m, incr+p; menos+m+q, artículo de intercambio+q+m, decr+q; +)).FUNCIÓN subir + >j + >p> + >m: menos+j+p; elemento más pequeño+m+p; inc+p, *.FUNCIÓN mover hacia abajo + >i + >q> + >m: menos+q+j; elemento más pequeño+q+m; decr+q, *.PRUEBA menos+>a+>b:=a"<"b.FUNCIÓN hacer+a>+>b:=a"="b.FUNCIÓN agregar+>a+>b+suma>:=suma"="a"+"b.FUNCIÓN reducir a la mitad+>a>:=a"/=2".FUNCIÓN incr+>a>:=a"++".FUNCIÓN decr+>a>:=a"--".PRUEBA de elemento más pequeño+>i+>j:="items["i"]<items["j"]".ACCIÓN intercambiar elementos+>i+>jt:=t"=items["i"];items["i"]=items["j"];items["j"]="t.Las operaciones primitivas se definen aquí en términos de Java (o C). Este no es un programa completo; debemos definir los elementos de la matriz Java en otro lugar.
CDL2, que apareció en 1976, mantuvo los principios de CDL1 pero hizo que el lenguaje fuera adecuado para proyectos grandes. Introdujo módulos, impuso el cambio de datos solo en caso de éxito y amplió un poco las capacidades del lenguaje. Los optimizadores en el compilador CDL2 y especialmente en el Laboratorio CDL2 (un IDE para CDL2) eran de clase mundial y no solo para su época. Una característica del optimizador CDL2 Laboratory es casi única: puede realizar optimizaciones en todas las unidades de compilación, es decir, tratar todo el programa como una única compilación.
CDL3 es un lenguaje más reciente. Renunció a la característica abierta de las versiones CDL anteriores y proporciona primitivas para la aritmética básica y el acceso al almacenamiento. La sintaxis extremadamente puritana de las versiones anteriores de CDL (el número de palabras clave y símbolos se expresan en un solo dígito) también se ha relajado. Algunos conceptos básicos ahora se expresan en sintaxis en lugar de semántica explícita. Además, se han introducido tipos de datos en el lenguaje.
El mbp Cobol comercial (un compilador Cobol para PC), así como el sistema MProlog (una implementación Prolog de potencia industrial que se ejecuta en numerosas arquitecturas (mainframe IBM, VAX, PDP-11, Intel 8086, etc.) y sistemas operativos. (DOS/OS/CMS/BS2000, VMS/Unix, DOS/Windows/OS2)). Este último, en particular, es testimonio de la portabilidad de CDL2.
Si bien la mayoría de los programas escritos con CDL han sido compiladores, existe al menos una aplicación GUI comercial que se desarrolló y mantuvo en CDL. Esta aplicación era una aplicación de adquisición de imágenes dentales que ahora es propiedad de DEXIS. En CDL también se desarrolló un sistema de gestión de consultorios dentales.
El software para la computadora de ajedrez Mephisto III fue escrito con CDL2. [1]