Typing in Visual Prolog and Mercury

Appeared in Volume 9/4, November 1996

Jonathan Lerwill
jonathan@pdc.dk
18th April 1996

Fergus Henderson wrote:
Is the type system of Visual Prolog the same as the type system that was in Turbo Prolog 1.0? If not, what are the differences?

1. When writing predicate definitions it is now possible to place a comment after each domain name. New types have been added to ease GUI programming.

2. Multiple internal (named) databases

3. Previous versions of PDC Prolog used Global Predicate definitions to define the interface between object modules. In Visual Prolog, the same technique (flow pattern descriptors) is applied to local predicates, generating a compile time error if an input parameter is used as output, etc.

fjh@mundook.cs.mu.oa.au
Fergus Henderson
19th April 1996

Tim Menzies writes:
How does that type system differ to that of Mercury?

There are two major differences, as well as several minor ones. The major (IMHO) differences are:

1. Mercury's type system supports parametric polymorphism whereas Turbo Prolog's does not. Turbo Prolog does have one polymorphic data type - lists are treated as a special case - but it doesn't allow any user-defined polymorphic data types or predicates.

2. Mercury's type system supports higher-order predicates, whereas Turbo Prolog's does not.

The minor differences are:

1. Turbo Prolog allows a predicate to have more than one type declaration. This mitigates somewhat the lack of true parametric polymorphism in Turbo Prolog. Mercury doesn't allow this sort of overloading. Mercury does allow overloading of two different predicates with the same name and arity, but they must be in different modules. I don't think Turbo Prolog allows this.

2. Mercury supports a "universal" data type called 'univ'; anything can be converted to type univ and back. If you attempt to convert a univ back to a different type than the one it was created from, the conversion will fail. This is a bit like a safe equivalent to C's 'void *'; it provides an "escape" for those rare occaisions on which you need to create heterogenous data structures.

3. Turbo Prolog supports a 'symbol' data-type, which is interchangeable with strings but has different performance characteristics - because symbols are stored in a symbol table, creation of symbols is slower, but equality tests can be a simple comparison. In Mercury, programmers tend to use enumerations instead, if the set of symbols in a type is known in advance. Enumerations in Mercury are represented as integers 0, 1, 2, ..., so they are more efficient than symbols would be.

4. Turbo Prolog allows implicit conversions from real to integer and vice versa (conversion from real to integer is done by truncation).

5. Although both Mercury and Turbo Prolog support defining one type as equal to another, the semantics are different. In Mercury, the two types are fully interchangable (just as with typedef in C). In Turbo Prolog, if two different types, say apples and oranges, are defined as equal to integer, Turbo Prolog will ensure that you don't mix apples and oranges. But it is only possible to define a type to be equivalent to one of the basic types (integer, char, real, string, or symbol).