Logic-based Software Representation

The CTC is based on a representation of software elements as logic facts. As an example, the figure below illustrates one of many possible fact representations for a Java program.

Representation of software by logic facts.

In the sample representation (adapted from JTransformer) each abstract syntax tree (AST) node of the program is represented as a logic fact. Nodes are linked by their identities. The first argument of each fact is the identity of the node that it represents. Identitites in other argument positions represent references to other nodes. Thus each fact can be seen as an adjacency list representation of a node in a graph. For instance, in the figure, every fact representing a node refers to its parent via its second argument.

Why Logic?

Logic programming has many advantages. It has a declarative semantics that makes it amenable to analyses, transformations and optimizations that are impossible in imperative languages, such as Java, because of side-effects and aliasing.

Declarativeness makes programs easy to write, understand and maintain. In addition, the multi-directionality of relational programming makes predicate definitions highly reusable.

Why not Prolog?

The main arguments against the “classic” incarnations of logic programming in languages of the Prolog family are:

  1. Inability to to express updates declaratively. Prolog has no declarative semantics for dealing with updates of the database, defeating the main motivation for logic: declarativeness.
  2. (In)Efficiency. The potentially extreme inefficiency of carelessly written Prolog programs makes them either inacceptable in practice or requires deep knowledge of the operational semantics and many programming idioms that defeats the potential advantages of declarative programming in terms of ease and simplicity.

Why CTs?

Our aim was the development of a model transformation language that provides the full advantages of unpolluted declarative programming, being easy to understand for programmers who otherwise use imperative languages and have no PhD in logic.

Therefore, we have addressed both of the above problems when designing the CT language:

  1. Declarative updates. The semantics of CTs overcomes the problems of Prolog interpreters, enabling a well-defined declarative semantics and an operational semantics that matches it precisely. So again, programmers can write CTs without having to care about the details of the operational implementation of the language.
  2. Compilation. A compiler tuned specifically for efficiency on large factbases, preprocesses the CT programs, performing automatically most of the tweaking that would otherwise burden developers, challenging their logic programming skills. Thus even novice programmers can write programs that will run efficiently. There is no need anymore to trade declarativeness for speed.
NOTE

The publicly available versions of the CTC do not include the compiler. How much of the compiler will be released under which terms and conditions remains to be determined.

Frequently Asked First Questions

Why not terms?

Relation to databases

Relation to Model Driven Software Engineering (MDSE)

Last modified: 2014/07/29 18:07
*