VisualProlog语言手册_visualprolog

prolog

需积分: 23 106 浏览量更新于2023-05-23 评论收藏 1.04MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

Visual Prolog 8

Language Reference

Prolog Development Center

www.visual-prolog.com

This document describes the syntax and semantics of the Visual Prolog programming language.

Visual Prolog is a strongly typed object oriented programming language based on the logical

programming language Prolog.

A Visual Prolog program consists of a goal and a number of:

n Interfaces

n Class declarations and

n Class implementations

Which contain declarations and definitions of Prolog entities:

n Domains

n Constants

n Predicates

n Properties

n Fact databases

The "actual" code of a Visual Prolog is the clauses, which are located in class implementations

and

which implements predicates.

Basic Concepts

Types and Subtypes

Types

Visual Prolog types are divided into object types and value types. Objects have mutable state,

whereas values are immutable.

Object types are defined by interface definitions.

The value types include numerical types, strings and character types and compound domains (also

known as algebraic data types). Simpler forms of compound domains are structure and enumeration

types, whereas more complex forms represents tree structures.

Subtypes

Types are organized in a subtype hierarchy. Subtypes are used to introduce subsumption-

polymorphism: Any context that expects a value of some type will equally well accept a value of any

subtype. Or if we turn it around, we can say, that values of a certain type are automatically

converted to any super-type where needed and can thus be used as having the super-type without

explicit type conversion.

Subtypes can be derived from any value type, except from algebraic data types. Types derived from

algebraic data types are synonym types rather than subtypes, i.e. they are the same type rather

than a subtype.

The notion of subtypes relates closely to the notion of subsets. But it is important to notice that

even though a type is "mathematically" a subset of another type it need not be a subtype. A type is

only subtype of another type if it is declared to be so.

domains

t1 = [1..17].

t2 = [5..13].

t3 = t1 [5..13].

t1 is an integral type whose values are the integers from 1 to 17 (both inclusive). Likewise, t2

contains the values from 5 to 13. So t2 is a subset of t1, but t2 is not a subtype of t1. On the

other hand, t3 (which contains the same values as t2) is a subtype of t1, because it is declared to

be so.

The language contains a few implicit subtype relations, but otherwise subtype relations are explicitly

stated in type definitions.

Object types are organized in a subtype hierarchy rooted in the predefined object type object, i.e.

any object type is a subtype of object. Object subtypes are defined by means of stating that one

interface supports another. If an object has an interface/object type that supports a certain other

interface, then the object also has that type and can without further interference be used as such

an object.

See also: Universal and Root Types

Object System

Visual Prolog 8

Language Reference

Page 2 / 172

External View

The description in this section is not supposed to be an introduction to classes; it is intended as a

clarification of the class notions in Visual Prolog. The reader is expected to be familiar with common

class notions. The description is purely conceptual in the sense that it does not refer to any syntax,

implementation, etc. Moreover, this description does not consider any operational or programmatic

aspects. While the reasons for introducing classes, objects, etc are mostly of programmatic nature,

we find it valuable to describe the underlying concepts without reference to these programmatic

reasons.

The class concept of Visual Prolog is based on the following three semantic entities:

n objects

n interfaces

n classes

Object

An object is set of named object member predicates and a set of supported interfaces. Objects

actually also have a state, but this state can only be changed and observed through the member

predicates. We say that the state is encapsulated in the object.

Here encapsulation means the ability of an object to hide its internal

data and methods, making only

the intended parts of the object programmatically accessible. The importance of encapsulation and

modularity is well known. Encapsulation helps building more structured and readable programs,

because objects are treated like black boxes. Look at a complex problem, find a part, which you can

declare and describe. Encapsulate it into an object, construct an interface and continue

so, until you

have declared all the sub-problems. When you have encapsulated the objects of the problem, and

ensured, that they work correctly, you can abstract from them.

Interface

An interface is an object type. It has a name and defines a set of named object predicates.

Interfaces are structured in a supports hierarchy (the structure is a semi-lattice rooted in the

interface object). If an object has a type denoted by an interface, then it also has the type of any

supported interfaces. Therefore, the supports hierarchy is also a type hierarchy. An interface is a

subtype of all its supported interfaces. We also say that the object supports the interface. If the

interface is named X, then we say that the object is an X, or an X object.

Class

A class is a named object factory; it can create objects corresponding to a certain interface. Any

object is created by a class, if an object was created by the class, which uses the interface C to

construct objects then we call it a "C object".

All objects that are constructed by a certain class share the same definition of the object member

predicates, but each object has its own state. Thus, the object

member predicates is actually part of

the class, whereas the state of the object is part of the object itself.

A class also contains another set of named predicates and an encapsulated state, known as the

class members and class state, respectively. The class members and the class state exist on a per

class basis, whereas the object members and object state exist on a per object basis. The class

state can be accessed both by class members and by object members.

Visual Prolog 8

Language Reference

Page 3 / 172

Notice! The set of object member predicates that a class defines is the union of the predicates

declared (transitively) in the interfaces of that class. More specifically this means that, if the same

predicate is declared in two different interfaces then the class will only provide one definition of that

predicate. So the class only sounds if that makes sense, i.e. if the intended semantics of these two

inherited predicates are the same.

Notice that interface support must be specified explicitly. The fact that some class provides the

predicates corresponding to some interface does not imply that the class supports the interface.

Module

In fact a class need not be able to manufacture objects at all. Such class may have only class

members and the class state. And therefore, such class can be considered to be a module rather

than a class.

Identity

Every object is unique: objects have a changeable state and since the state of the objects can be

observed by means of their member predicates an object is only identical to itself. I.e. even if the

states of two objects are identical, the objects are not identical, because we can change the state

of one object without changing the state of the other object.

We never have direct access to an object state, we always access an object state by means of a

reference to the object and while an object is only identical to itself, we can have many references

to the same object. Thus, the same object can be accessed through many different references.

Classes and interfaces are also unique; they are identified by their names. Two interfaces or classes

cannot have the same name in the same program. A class and an interface can only have the same

name if the class constructs objects of that interface.

The essence is that structural equality does not imply identity for objects, classes nor interfaces.

Internal View

Where the previous section described objects, classes, and interfaces in terms of their external

behavior, this section will extend this description with internal

issues. These internal issues have more

programmatically nature; they are concerned with splitting of classes onto the declaration part and

the implementation part.

From a programmatic point of view, classes are the central item: the code is contained in the

classes.

Interfaces mainly have static importance. In fact, interfaces only exist in the textual representation

of a program; there is no (direct) runtime representation of an interface.

Objects, on the other hand, have mainly dynamic importance. Objects are not directly visible in the

program; they do not exist until the program actually runs.

A class consists of a declaration and an implementation. The declaration declares the public

accessible parts of the class and the objects it generates. The implementation on the other hand

defines the entities declared in the class declaration. The basic implementation of predicates is of

course clauses, but predicates can also be defined by means of inheritance, or resolved to external

libraries.

A class declaration in Visual Prolog is purely declarative. It only states which

entities you can access:

Visual Prolog 8

Language Reference

Page 4 / 172

not how or where they are implemented.

A class implementation can declare and define further entities (i.e. domains, predicates, etc), which

are only visible inside the class itself. I.e. they are private.

The state of an object is stored in the object as its facts. These facts are declared as normal facts

(database) sections in the implementation of the class. Facts are local to each object (like other

object entities), whereas class facts are shared among all objects of the class.

Facts can only be declared in the implementation of a class and, therefore, cannot be accessed

(directly) from outside the class.

The implementation of a class can also declare that it supports more interfaces

than mentioned in the

declaration. This information is, however, only visible in the implementation itself and is, therefore,

private.

Code Inheritance

In Visual Prolog code inheritance only takes place in the implementation of a class. Visual Prolog has

multiple inheritance. You inherit from a class by mentioning the class in a special inherits section of

the implementation. The classes you inherit from are called parent classes or super-classes. Child-

class or sub-class is the dual to parent class, we also say that the child classes inherit from the

parent classes. A child class can only access its parent classes through its public interface, i.e. it

does not receive any extra privileges than anybody else that use the parent class.

Scoping & Visibility

Name Categories

All names (identifiers) in Visual Prolog are syntactically divided into two major groups:

n Constant names (starting with a lowercase letter)

n Variable names (starting with an uppercase letter or an underscore)

Constant names (identifiers) are divided into the following categories:

n Type names (i.e. domains and interfaces).

n Domain carriers (i.e. classes and interfaces).

n Names without parentheses (i.e. constants, fact variables of non-function type and nullary-

functors).

n Value returning names of arity N (i.e. functions, functors and fact-variables of function type).

n Non-value-returning names of arity N (i.e. predicates, facts and fact variables of predicate

type).

Visual Prolog demands that names do not conflict at the point of declaration, because then it would

be impossible to solve the conflict at point of usage. Declarations can only conflict if they are in the

same scope, because qualification with scope can be used to solve the conflict. A name in one

category can never be in conflict with a name in another category, but as we shall see a single

declaration might place a name in several categories.

Packages

The basic units of code organization accepted in Visual Prolog are packages. We use packages in

Visual Prolog to organize and structuring things. The use of packages ensures homogeneity in

Visual Prolog 8

Language Reference

Page 5 / 172

剩余171页未读，继续阅读

子不语Bily

粉丝: 1
资源: 2

会员权益专享

Visual Prolog语言手册

评论0

会员权益专享

最新资源

Visual Prolog语言手册

评论0

Visual Prolog 7.5 语言参考手册

visual prolog 9 个人版

visual prolog 7 边学边练 中文版

Prolog语言中移动环境的类型推断

基于Prolog的OWL查询语言

visual prolog安装教程

Visual PROLOG程序设计基本知识

visual prolog初学

visual prolog教程

visual prolog

visual prolog使用教程

我用的程序是这个Visual Prolog 5.2 ，请你基于这个程序写一个简单完整的 Turbo prolog 程序，注意，代码要符合这个Visual Prolog 5.2程序

swi prolog 中文手册

Visual prolog软件编程方法 状态图和与或图搜索的基本算法 图搜索问题求解中的问题表示、节点表示、close表和open表的构造。

报了一堆错误，我用来编写prolog的程序是visual prolog是5.2版本，请你重写上述代码，要符合我这个5.2版本的

我用的编辑器是这个Visual Prolog 5.2 Personal Edition，请你基于这个编辑器的环境写一个简单完整的 Turbo prolog 程序

1. 掌握Visual prolog软件编程方法； 2. 熟悉状态图和与或图搜索的基本算法； 3．掌握图搜索问题求解中的问题表示、节点表示、close表和open表的构造。

我的visual prolog版本是5.2，请你基于该版本修改上述你给我写的代码

Prolog语言及逻辑程序设计

1、熟悉PROLOG语言编程环境的使用； 2、了解PROLOG语言中常量、变量的表示方法； 3、了解利用PROLOG进行事实库、规则库的编写方法。 实验小结

会员权益专享

最新资源

visual prolog 7 边学边练中文版

Visual prolog软件编程方法状态图和与或图搜索的基本算法图搜索问题求解中的问题表示、节点表示、close表和open表的构造。

1、熟悉PROLOG语言编程环境的使用； 2、了解PROLOG语言中常量、变量的表示方法； 3、了解利用PROLOG进行事实库、规则库的编写方法。实验小结