Visual Prolog Object System

(Report at APPSEM II Workshop 2005)

Thomas Linder Puls & Carsten Kehler Holst

 Prolog Development Center A/S

Abstract

Visual Prolog is a logical and object-oriented programming language descended from Turbo Prolog and PDC Prolog. It comes with an integrated development environment (IDE). The language is fully compiled and can be linked with for example C++ code. Prolog Development Center has developed several versions of the language since 1983 and uses it as the primary development language for its applications, most of which are graphical planning and scheduling applications. Currently we are using version 6.3 of the language and implementation (see below) and is in the process of implementing version 7.X. Since the development of version 6.0 we have implemented a full set of foundation classes including an object oriented GUI framework. In this extended abstract we give an overview of the language in a historical setting and a slightly more in depth description of the object oriented features introduced in version 6 and our experience with them through the last 4 years.

Historical:

• Logical programming language based on Prolog
• Algebraic data types (pattern-matching, unification)
• Nondeterminism (depth first searches)
• Fact databases
• Strongly typed
• Determinism analysis (mode analysis)
• Automatic memory management based on the Warren Abstract Machine

Vip6.x (our current development platform):

• Class based object system:
  • Clear separation of declarations and implementations
  • Clear separation of object types and classes
  • Clear separation of sub-typing and inheritance
  • "delegate to"
  • "predicates from"
  • Object callback predicates
• Nested expressions
• Garbage Collection (Boehm, et. al.)

Future updates Vip7.x (next generation of the language to be released shortly):

• Parametric Polymorphism/Generics
  • Parametric types
  • Parametric predicates
  • Parametric interfaces
  • Parametric classes
  • F-bounded polymorphism
  • Type libraries
• List comprehension
• New language constructs (foreach, if-then-else)
• "Lambda expressions"
• Compiling pattern matching to case statements
• Name spaces
• "Protected/Friends" methods

Object System

The class based object system in Visual Prolog is based on the idea of separating class declarations from their implementation, so that class declarations can be used as "contracts" between the implementation and the usage of the class.

The object system isolates a number of notions in orthogonal features, which are mixed in other object-oriented languages.

Object types are completely isolated from classes: A class constructs objects of a certain type, but it does itself not define a type. All types are defined solely by interface definitions, and any class can create objects of any one object type it likes (i.e. the programmer likes). This clear separation of objects and the classes that implements them makes it simpler to create object type hierarchies with focus on usage rather than implementation. Such class-liberated interfaces can be implemented by several different classes (so it is not even possible to prevent subsumption polymorphism). On the other hand it, does give problems with having "protected" methods and "friends" in the C++ sense.

Subtyping is completely separated from inheritance: Subtyping solely relates to object types, i.e. interfaces. Whereas inheritance solely relates to classes, and in fact is a completely private matter. Inheritance can only be expressed as part of the implementation of a class, and is completely hidden from the usage of the class.

Separating subtyping and inheritance gives a good opportunity to understand and code problems like this: We are studying persons of a certain tribe, and need to represent these persons in our program.

Occasionally we do however also need to represent persons from other tribes. So we consider inheriting from our first class and add a "tribe field". In most object-oriented programming languages this gives a problem, because if you extend with an extra field you also subtype the original class. But the subtype relation clearly goes the other way: persons from our specific tribe is clearly a subset of persons from any tribe. Our base class does not correspond to not having the tribe field; it corresponds to having a specific (and therefore suppressed) value of this field. In Visual Prolog this problem is not a problem, the type representing our specific tribe can be a subtype of the type of persons from any tribe, and the classes implementing people from any tribe can inherit from the class implementing persons from our specific type.

Having the notions orthogonally separated makes Visual Prolog very well suited for learning/teaching about these notions.

Often one object needs to delegate methods to another object, in Visual Prolog there is a simple language construct for doing such delegation. You simply write "delegate <interface or method> to yyy" where yyy is an object or class variable containing the object to delegate to. The compile time type check ensures that yyy indeed holds an object with the relevant interface or method. Delegation is in many respects similar to inheritance, only the object to "inherit" from is completely dynamical.

Often when designing an object representation you like to create some support classes, these often implement a subset of the functionality that you really want to provide. Other classes will then extend the support classes to provide the full functionality. This very easily creates a cluttered type hierarchy to the end user, because the support class becomes visible to the end user and its interface even plays part of the final interface the user sees. Visual Prolog offers a way to define super interface types for situations like this. Specify the interface that you want to present to the end user of the class and then define the interface of the support class as a supertype of this interface, using the "predicates from …" (predicates are the methods in Visual Prolog objects).

In Visual Prolog object methods can be passed as argument, stored in variables, etc. Furthermore, when the method is invoked it is executed in the context of the object that owns the method. This is similar to delegates from C++, only without the programming (and conceptual) overhead of dealing with the delegate object.

Experience

It is difficult to asses whether the orthogonal design has had positive impact on productivity compared to some other not chosen design. But it works in practice as witnessed by our foundation classes and several big > 200.000 lines applications. The “predicates from” construction has proven to be very useful when designing supporting classes without getting a cluttered inheritance hierarchy. And the “delegate” construction offers a flexible alternative to inheritance that often works better when you have an aggregated object or one with aggregated responsibilities.

Prolog Development Center was founded on programming language technology and we still believe that a good and innovative programming language is an integral part of keeping a high productivity and producing good and technically innovative applications.

Further information about the language and a free version of the system for non commercial use can be found at our web site www.visual-prolog.com.

Related works

The development of Visual Prolog is inspired by many sources. We are clearly inspired by theoretical work and contemporary trends, but we are also very much driven by the needs and wishes of in-house programmers. The original Turbo-Prolog system is based on work by Jørgen Fischer Nilsson (On the Compilation of a Domain-Based Prolog, IFIP Congress, 1983, p. 293-298). Mercury (www.cs.mu.oz.au/research/mercury/) which is also a logical programming language has many similarities to Visual Prolog, although recent development has lead the systems more apart. The object system in Visual Prolog is inspired by many but not very specific sources. Being a commercial company, rather than a research institution, we do not keep much track of our sources; it is the result that matters. The object system is based on the ideas of C++, but it tries to overcome some of its problems by applying modern ideas and to be less "compiler pragmatic" and focus more on programmer pragmatics.