Compiler Description Language
From Wikipedia, the free encyclopedia
Compiler Description Language, or CDL, is a Computer language based on affix grammars. It is very similar to Backus–Naur form(BNF) notation. It was designed for the development of compilers. It is very limited in its capabilities and control flow. Although the language looks a bit like Prolog, control flow is entirely based on success/failure: there is no logical NOT-operator in CDL3.
CDL3 is very difficult to program in. Because it is mainly used in academic context, the documentation is difficult to navigate. Furthermore, CDL3 has a compiler with uninformative error messages, and the language does not allow naming of variables: all variables of type T (e.g. INT, TEXT) are named T0, T1, T2, and so forth. This can be worked around using defines (similar to C #define), but this is a fairly messy solution.
CDL3 is the third version of the CDL language, significantly different from the previous two versions.
[edit] Short Description
The original version, designed by Cornelis H. A. Koster at the University of Nijmegen emerged in 1971 had a rather unusual concept: it had no core. A typical programming language source is translated to machine instructions or canned sequences of those instructions. Those represent the core, the most basic abstractions that the given language supports. Such primitives can be the additions of numbers, copying variables to each other and so on. CDL1 lacks such a core, it is the responsibility of the programmer to provide the primitive operations in a form that can then be turned into machine instructions by means of an assembler or a compiler for a traditional language. The CDL1 language itself has no concept of primitives, no concept of data types apart from the machine word (an abstract unit of storage - not necessarily a real machine word as such). The evaluation rules are rather similar to the Backus–Naur form syntax descriptions; in fact, writing a parser for a language described in BNF is rather simple in CDL1.
Basically, the language consists of rules. A rule can either succeed or fail. A rule consists of alternatives that are sequences of other rules. A rule succeeds if any of its alternatives succeeds, an alternative succeeds if all of its rules succeed. In an informal manner, a CDL rule is along the lines of 'rule X is true if A and B and C are true or if A and F and G are true or if T and H and Z and J are true.' The language provides operators to create evaluation loops without recursion and some shortcuts to increase the efficiency of the otherwise recursive evaluation but the basic concept is as above. Apart from the obvious application in context-free grammar parsing, CDL is also well suited to control applications, since a lot of control applications are essentially deeply nested if-then rules.
Each CDL1 rule, while being evaluated, can act on data, which is of unspecified type. Ideally the data would not be changed unless the rule is successful. This causes problems as although this rule may succeed, the rule invoking it might still fail, in which case the data change should not take effect. It is fairly easy (albeit memory intensive) to assure the above behavior if all the data is dynamically allocated on a stack but it is rather hard when there's static data, which is often the case.
As the rule evaluation is based on calling simpler and simpler rules, at the bottom there should be some primitive rules that do the actual work. That is where CDL1 is very surprising: it does not have those primitives. You have to provide those rules yourself. If you need addition in your program, you have to create a rule that has two input parameters and one output parameter and the output is set to be the sum of the two inputs by your code. The CDL compiler uses your code as strings (there are conventions how to refer to the input and output variables) and simply emits it as needed. If you describe your adding rule using assembly, then you will need an assembler to translate the CDL compiler's output to machine code. If you describe all the primitive rules (macros in CDL terminology) in Pascal or C, then you need a Pascal or C compiler to run after the CDL compiler. This lack of core pimitives can be very painful when you have to write a snipet of code even for the simplest singe-machine-instruction operation but on the other hand it gives you very great flexibility in implementing esoteric abstract primitives acting on exotic abstract objects (the 'machine word' in CDL is more like 'unit of data storage', with no reference to the kind of data stored there).
CDL2, that appeared in 1976, kept the principles of CDL1 but attempted to make the language suitable for large projects. It introduced modules, attempted to enforce the data-change-only-on-success and extended the capabilities of the language somewhat.
CDL3 is a more recent language. It gave up the open-ended feature of the previous CDL versions and it provides primitives to basic arithmetic and storage access. The extremely puritan syntax of the earlier CDL versions (the number of keywords and symbols both run in single digits) have also been relaxed and some basic concepts are now expressed in syntax rather than explicite semantics. In addition, data types have been introduced to the language.
An book about the CDL1 / CDL2 language can be found in [1].
The description of CDL3 can be found in [2].
[edit] Programs Developed
While most programs written with CDL have been compilers, there is at least one commercial GUI application that was developed and maintained in CDL. This application was a dental image acquisition application now owned by DEXIS. As proof that nearly any language can be used to develop nearly any application, it stands as a singular and unique achievement. A dental office management system was also once developed in CDL.
