reix@s9ia.ec.bull.fr (01/12/90)
Here is a brief description of the SP-Prolog compiler v2.1 and of SP-Object,
its object extension.
The original paper of SP-Object (with nice pictures) is available.
Just send me a mail with your address if you want it.
!! CUT HERE -------------------------------------------------------------------
SP-Prolog, a truly industrial Prolog
by Ph. Donz
Head of the Knowledge System Department
in the UNIX Center of Bull SA
1, rue de Provence - B.P. 208 - 38432 Echirolles Cedex FRANCE
Tel. : (33) 76.39.75.00 extension 73.31
EMail : Philippe.Donz@ec.bull.fr
10 years work on the implementation and use of Prolog:
Doctor specialized in Artificial Intelligence, diploma obtained
at the GIA (Groupe Intelligence Artificielle) laboratory
at Marseille-Luminy, under the direction of A. Colmerauer,
the creator of Prolog.
designer/developer of the CRISS (Research Center for Data Processing
applied to Social Sciences) Prolog interpreter,
co-founder of Delphia Company,
designer/developer of the D-Prolog (Delphia product) interpreter,
co-writer of the book entitled "D-Prolog Language",
head of the SP-Prolog (registered trademark) project at Bull SA.
I. OVERVIEW
SP-Prolog is a Prolog system designed and developed by Bull SA.
It allows you to create, interpret and debug, then to compile and run
Prolog programs.
This state-of-the-art comprehensive Prolog system includes the following tools:
- a compiler,
- an interpreter,
- trace facility,
- a utilities library,
- a graphic and multi-window library,
- a graphic development environment.
This Prolog offers many extensions such as modularity, deferred calls,
external interfaces to C language, escape and exception handling.
SP-Prolog generates executable modules independent of the development
environment.
An "Object Oriented Prolog" extension is included in version 2 of the
SP-Prolog system.
II. OPENING
As an introduction, we should bear in mind that Artificial Intelligence
applications are not generally properly integrated in traditional data
processing.
We were therefore guided by two main requisites in designing the SP-Prolog
product:
1. An SP-Prolog application should easily and efficiently interface with
existing tools and services (languages, system, graphics, data bases,
communication, applications, etc.).
1. An existing application should be able to support services offered by
an SP-Prolog library (expert systems, natural language interface,
intelligent data processing, etc.).
To meet these requirements, an original A.I. architecture was adopted:
i. Product architecture
At the core of the SP-Prolog system lies the compiler.
This is the only Prolog compiler that was, from the outset, designed
for integration into a conventional software production chain.
The SP-Prolog plc compiler is used like the C cc compiler:
From a Prolog source, plc generates a target machine assembler source
code which is assembled by the host system assembler.
Binary files that are thus generated can then be linked with any other
binary modules or libraries and they become executable modules with
the format of the host system.
An SP-Prolog application may then use libraries (mathematic or graphic,
for instance), or an existing application may use SP-Prolog libraries
(expert system or intelligent interface with a relational data base
management system, for instance).
The other products currently available on the market are either
incremental compilers which are unable to generate runtime modules
independent of the Prolog development environment, or chargeable
runtime generators using their own memory management, that cannot
be linked with realistic applications.
ii. Interfaces
The architecture chosen allows SP-Prolog to interface easily with the C
language. There are two types of interfaces:
- foreign (C type Prolog parameters: character strings, integers
or real numbers) for immediately reusing C functions,
- alien (handling of any Prolog terms) for developing complex
predicates.
C or Prolog may be master (main()) of the application.
III. DEVELOPMENT ENVIRONMENT
A second observation is that Artificial Intelligence products, before
they can be used, must be developed.
This requires providing a sound development environment.
i. Interpreter/Compiler
SP-Prolog includes an interpreter (for development) and a compiler
(for application generation).
An application may include both compiled code and interpreted code.
ii. Trace facility
The trace feature can trace interpreted programs as well as
non-optimised compiled programs.
You may also use it to set imperative or conditional break points,
to trace step by step, or to trace a goal, either depth first or
breadth first (zoom).
iii. Debugging environment
The tools (interpreter, tracer, editors, snoopers, etc.) are available
in a graphic environment.
This environment is as follows:
- a set of menus offering a selection of functions,
- a set of dedicated windows (session, trace, editing, system, message,
snooper).
IV. MODULARITY
As a third observation: Artificial Intelligence products do not provide
all the means required to modularise large size applications.
SP-Prolog allows using separately compiled Prolog modules.
Modularity is based on the scope of symbols (atoms, structure functors and
predicates): a symbol may either be global (visible by several modules) or
local (visible only within its own module).
Directives (global, hidden, use, export, import from) can be used to modify
the default scope of symbols.
SP-Prolog not only allows organizing an application into modules, but also
hiding the data within these modules: a symbol in module A cannot be seen
by another module B, unless the owner of module A has expressly permitted it.
V. BASE TYPES
Fourth observation: Many Artificial Intelligence products provide
"twisted" base types that are not compatible with the base types of
conventional languages.
i. Numbers
Unlike other Prologs offering 31-bit real numbers and 28-bit integers,
SP-Prolog handles integers and real numbers in 32-bit format.
ii. Character strings
SP-Prolog is one of the first compilers implementing character strings,
which circumvent the inefficiency of the traditional character lists.
VI. FUNCTIONALITIES
i. Base mechanisms
SP-Prolog includes both the conventional functionalities of Anglo-Saxon
Prolog versions (C-Prolog of the University of Edinburgh), Quintus Prolog
of Quintus Computer Systems): work space (record), sophisticated trace
facilities, etc., and those less usual functionalities such as Marseille
Prolog (Prolog II of Prologia): deferred calls (freeze), escapes, and
exception handling (block).
It also includes a set of metalogical predicates useful for instance
for the development of expert systems.
ii. Graphics
SP-Prolog provides a library of graphic and windowing functions for
the Bull graphic server or DPX1000 graphic monitor (X-Window).
VII. STATE OF THE ART
Implementation of SP-Prolog relies on the basics of the Warren Abstract
Machine (An abstract Prolog instruction set, SRI International, AI center,
1983) which is to this day the best Prolog implementation model on
conventional computers.
SP-Prolog implements the following optimizations as standard features:
mode declaration, clause indexing and Tail Recursion Optimisation.
VIII. PERFORMANCE
SP-Prolog is up to the standards of Quintus Prolog, its main rival.
The performance of SP-Prolog on the "nrev" test, are 80 KLips in compiled
mode and 10 KLips in interpreted mode on a 68020 microprocessor operated
at 16 MHz.
Using a real Prolog application as a benchmark (Chat: a natural language
query software from a geographical data base, developed by Warren, 5500
lines of Prolog), the following results were obtained in compiled mode:
- 14.3s for Quintus Prolog 2.0 on a Sun 3/160 system,
- 17.0s for SP-Prolog 1.6 (with freeze) on a DPX1000 workstation,
- 9.87s for SP-Prolog 1.6 (with freeze) on a DPX5020 computer,
- 10.5s for SP-Prolog 1.6 (with freeze) on a DPS7-1007 mainframe.
The freeze mechanism available in SP-Prolog degrades runtime performance
by approximately 10%.
Conventional so-called KLips measurements are meaningless.
Based on programs of a few lines only, the results cannot be extrapolated
to determine performance of a real application.
Moreover, a number of source to source optimization techniques can be used
to convert conventional recursive tests into iterative tests.
However, these optimization techniques can only be applied to a limited
number of Prolog programs.
IX. PORTABILITY
SP-Prolog is designed for quick portability to various types of hardware.
The following systems are already proven for portability:
- RISC computer: DPX 5000 based on the Ridge.
- Conventional System: DPX1000/2000 based on 680x0.
- Micro System: BM600 based on Intel 80386, with IX.
- Conventional Mainframe: DPS7 (segmented architecture).
X. COMPLIANCE WITH THE STANDARDS
SP-Prolog complies with the Edinburgh syntax standard and is compatible
with C-Prolog university standard.
Bull SA is currently taking part in the ISO Prolog standardization effort.
XI. OBJECT EXTENSION
SP-Prolog Object extension is based on the concepts developed in the
Smalltalk-80 (registered trademark of Xerox Corporation) language.
This model was adapted to the peculiarities of the Prolog language.
This extension is completely integrated inside the SP-Prolog system.
XII. BY-PRODUCTS
Via the SP-Image system, SP-Prolog provides a user interface description
and management tool.
This tool was developed using the SP-Prolog object system and the graphic
and windowing system.
It offers a base for enriched environments (SP-Prolog development environment,
editors and user interface builders).
With the SP-Access product, SP-Prolog also provides for connection of
Prolog to relational data bases (e.g. Oracle of Oracle Corporation),
to file management systems such as C-Isam (of Informix Software) and
access to a Prolog external data base (as opposed to the internal data
base available in Prolog).
!! CUT HERE -------------------------------------------------------------------
SP-Object
Object Extension in the SP-Prolog v2.1 System
Tony Reix
A.I. Engineer - CEDIAG - Bull SA
1, rue de Provence - BP 208
38432 ECHIROLLES Cedex - FRANCE
Tel. : (33) 76.39.75.00 extension 72.67
EMail : Tony.Reix@ec.bull.fr
1. INTRODUCTION
SP-Prolog is the Prolog System chosen by Bull SA.
It was launched in the middle of 1985 by the Knowledge Systems Department
(SCO) of the Bull SA Unix Center, in Grenoble.
SP-Object was designed in 1987 and implemented in 1988 by the SCO and
CEDIAG (Center of Study and Development in Artificial Intelligence of
the Bull Group) departments.
The SP-Prolog language is used to group within modules the predicates
of an application and to organize its non-volatile data in the form of
linked records, which is quite sufficient for a conventional application.
However, for an application where the non-volatile data are heavily
structured and can be classified with respect to a hierarchy, an object
oriented approach offers unquestionable benefits.
Therefore we decided to include in SP-Prolog version 2 an Object Oriented
Extension based on the Smalltalk-80 (of Xerox Corporation) Object Language
concepts, simplified and adapted to SP-Prolog.
This extension is not obtained by means of a Prolog layer or a pre-
processor but by a complete integration inside the SP-Prolog system.
Such an integration ensures the development environment quality
(interpreter and trace facility), and makes it possible to exploit the
SP-Prolog system benefits, particularly concerning the separate compiling
of classes and the generation of executable run-times.
1.1 Benefits of Object Oriented Programming
The main advantage of Object Oriented Programming (OOP) is to offer in
an easy and natural way structural representation of the bulk of data
handled by an application: their definitions are no longer scattered in
scores of procedures and files, but grouped physically and logically
with the procedures handling them.
This is known as the encapsulation concept: the same entity (a class)
contains the description (fields) of the data handled (objects), as
well as the programs (methods) handling them.
Therefore, a Class stands out both as the definition of a data type and
as a set of procedures.
An Object is a physical representation (an instance) of the type defined
by its class.
A conventional data processing application simulates a natural
organization implementing complex relations between numerous entities.
Object Oriented Programming makes it possible to base the organization
of computer entities on the organization of the real world entities
to be modelled.
It is thus possible to significantly bridge the semantic gap between
the real world to be described and the data processing language used
to represent it, which simplifies application modelling.
Besides, OOP is a permanent incentive to abide by the software
analysis and designing rules: first of all, by defining entities
(classes and objects) to be handled, then by concurrently defining
the data structures (fields) of these entities and their behavior (methods).
Fields and methods shared by different classes are "factorized" by
means of inheritance.
Another benefit of OOP lies in the concepts of class and heritage
which allow for intrinsic reusing of the software.
This fosters the creation of program libraries.
1.2 Prolog and Object Oriented Programming
It has quite often been said that Object Oriented Programming is to
the 1980s what Structured Programming meant to the 1970s.
Adding OOP to SP-Prolog helps fostering an object oriented structured
programming style and improving the maintainability of programs.
Several studies and industrial projects have already experimented
with the addition of OOP to Prolog: ESP (ICOT), LAP (IIRIAM), Phocus
(ECRC), Emicat (ESD) etc.
However, in our opinion, none of these projects has yielded satisfactory
results, due to:
- inadequate integration with the host Prolog (Prolog layer),
- intrinsic inefficiency (Prolog encoding),
- overspecialized semantics (Expert System generator), or
- a too complex base model (multiple inheritance, daemons).
SP-Prolog + Objects should meet the following requirements:
- make use of simple concepts,
- allow efficient execution,
- offer a base language instrumental in building up super-sets, and
- offer perfect integration with the SP-Prolog system.
After studying the various existing Object languages, we decided to
build up the Object semantics of our system on the basis of the
Smalltalk-80 language concepts.
Indeed, to this day, Smalltalk-80 is the best defined and proven Object
language: its concepts have stabilized since 1980 and have been used
with satisfaction by a great number of users.
SP-Object uses the core of the Smalltalk-80 concepts, simplifying
and adapting them to SP-Prolog.
2. OBJECT EXTENSION IN SP-PROLOG
2.1 Semantics
The type of inheritance offered is the simple inheritance, which is
more than sufficient for most of the applications.
Inheritance implementation is based on the same inheritance tree and
on the same instanciation graph as Smalltalk/V (of Digitalk), a subset
of Smalltalk-80.
A class is regarded by the user as a single entity describing two
behaviors (fields and methods):
- that of the class itself (a class is therefore an object),
- that of the instances of the class.
A class may contain method or predicate definitions.
However, only the methods can be activated from outside, using messages,
while the predicates are used to write the methods.
Created objects can be anonymous (typed Prolog term named objref) or
named (global or local atom).
The only way to communicate with an object is to send it a message.
When an object receives a message, the definition of a method is
looked for in the inheritance of its class and, then, the method is
activated as a Prolog predicate, with unification of the arguments.
The execution of the method can be either acting on its data
(modification or inquiry) or executing actions (message sending,
predicate call).
There are 2 ways of sending a message:
- simple: search starting from the class of the object,
- super: search starting from the super-class of the class where
the message is found.
Sending a super message makes it possible to reuse a method described
further up in the hierarchy.
An object may have 2 types of fields:
- named fields: accessed by a name.
- one indexed field: accessed by an index, and with a variable size.
Various very efficient primitives can be used to access in read/write
mode the value of the named or indexed fields of an object, as well as
the fields of its class.
A field, which is undefined upon creation of the object, may take on
any Prolog term as a value.
The fields of an object can only be handled within the class which
defines them or within the subclasses of the latter, unless one of
these classes proposes appropriate access methods.
In this way, SP-Object complies with the Smalltalk-80 model, although
it also makes it possible to limit the visibility of the fields of an
object inside the inheritance tree: a class may define hidden fields
accessible only from within this class.
User classes can be compiled (definitions are not modifiable) or
interpreted (super-class, number of fields, indexation, and method
definitions can be changed): after having developed classes in
interpreted mode, the user can compile and add them to its interactive
environment.
For safety, compiled classes cannot be sub-classes of interpreted classes.
SP-Object contains a set of preset compiled classes providing basic
operations on objects and classes: investigation, copies, printout of
field values, dynamic creation/deletion of object, class, field and method.
2.2 Syntax
Message sending is explicit to provide for better differentiation
between predicate calls.
Accesses to the fields and the super message implicitly concern the
object receiving the message.
Class example:
% The class point, subclass of object
( 1) :- subclass point of object.
( 2) <<- new(O) :-
( 3) <<<- new(O),
( 4) O <<- init.
( 5) :- instance.
( 6) :- fields x,y.
( 7) <<- init :-
( 8) origin(X,Y),
( 9) <<- put_val(x,X),
(10) <<- put_val(y,Y).
(11) origin(0,0).
1. Definition of the class called point, a subclass of object, root of
the kernel classes. Beginning of the description of the behavior of point.
2. Definition of <<-new/1, a class method.
3. Super message sending (to point).
4. Simple message sending.
5. Beginning of the description of point instances behavior.
6. Each instance of point has two named fields: x & y.
7. Definition of <<-init/0, an instance method.
8. Acquisition of the origin defined with a predicate.
9. Access the x field for a write.
10. Access the y field for a write.
2.3 Integration with SP-Prolog
The object extension is fully integrated in SP-Prolog: the classes
(field and method definition, access to the fields) may be compiled,
appended into a library, interpreted, consulted and saved/restored in
the same way as a module.
SP-Prolog has been designed to integrate into the conventional software
production chain. The SP-Prolog plc compiler is used like the C cc compiler:
From a Prolog source, plc generates a target machine assembler source
code which is assembled by the host system assembler.
Binary files that are thus generated can then be linked with any other
binary modules or libraries and they become sharable executable modules
using the format of the host system.
A SP-Prolog application using modules and classes may then use libraries
(mathematical, graphic, ...), or an existing application may use SP-Prolog
libraries (such as graphic interface classes): C or SP-Prolog may be the
main() of the application.
SP-Prolog interfaces easily with the C language by means of two
types of interfaces:
- foreign (C type parameters) for immediately reusing C functions,
- alien (any Prolog types as parameters) for complex predicates.
The trace facility of Prolog predicates has been extended so as to
allow for the tracing of messages sent and of object fields access:
- to acquire information on the search and the definition of the
accessed method or field,
- to indicate the class of the object receiving the message, and
to display the values of its fields.
One can trace interpreted as well as non-optimized compiled programs.
You may set imperative or conditional break points on methods, trace step
by step, skip, zoom or retry a message, as you do for a predicate call.
Tools (interpreter, tracer, and browsers of classes, modules and objects)
are available in the plw graphic development environment.
The modularity of SP-Prolog is based on the scope of symbols (atoms,
structure functors, and predicates): a symbol may either be global
(visible by several modules) or local (visible only within its own module).
Directives (global, hidden, use, export, import from for modules; use,
import from for classes) can be used to modify the default scope of symbols.
SP-Prolog not only allows organizing an application into modules and
classes, but also hiding the data within these modules: a symbol in
module A cannot be seen by another module B, unless the owner of module
A has expressly permitted it.
Like SP-Prolog, SP-Object handles integers and real numbers in 32-bit format.
Object fields can contain character strings, which circumvent the
inefficiency of the traditional Prolog character lists.
Two very useful SP-Prolog functionalities can apply on messages:
- delayed message sending (freeze): the execution of a message is
delayed until a distinctive variable is instanciated,
- definition of labelled escape handler (block): if an escape
corresponding to a label occurs during execution of a message,
control is passed directly to a handler.
Implemented on the basics of the Warren Abstract Machine (HLPAM) and
on a Prolog Virtual Assembler (LLPAM), and designed for quick portability
to various types of hardware, SP-Prolog and SP-Object has been ported
on Unix systems:
- Ridge Risc,
- Motorola 680X0,
- Intel 80386,
and on the Bull GCOS7 Mainframe system:
- DPS 7000.
Using the conventional KLips nai~ve reverse Prolog benchmark on a DPX 5000,
we obtained in interpreted mode:
- 11 KLips for the nrev predicate call,
- 8 KLips for the nrev message sending.
Optimizing techniques could be used to compile the inheritance of
methods completely.
The Object Garbage Collector recovers all the objects left unused
by searching all living objects (Object Memory) and Prolog areas.
Useless living objects may be released explicitly.
2.4 Predefined Methods
Kernel classes offer a set of predefined methods:
Object Copy:
- shallowCopy/1 creates a copy whose fields are identical to those of
the copied object.
- deepCopy/1 creates a complete copy taking recursive objects into account.
- deepCopy/2 gives also the corresponding list between original objects
and copied objects.
Object modification:
- become/1 exchanges the identity of 2 objects.
- free/0 says to SP-Object that an object is now useless.
Acquiring the object characteristics:
- class/1 gives the name of the class.
- size/1 and indexSize/1 gives the whole size and the size of
indexed field.
- dump/0 displays the class, size, and field name/value of an object.
Acquiring the class characteristics:
- fieldsArray/1 gives the array of names of the fields defined by
the class.
- fieldsNumber/1 gives the total number of named fields for the instances.
- superClass/1 gives the name of the super-class, and subClassesArray/1
gives the array of sub-classes.
Instance management:
- new/1 and new/2 create instance with or without indexed field.
- instancesArray/1 gives the array of instances (dead or alive) of a class.
Interpreted classes management:
- subClass/1 creates an interpreted sub-class of the class.
- remClass/1 destroys an interpreted class.
- addFields/1 and remFields/1 allow adding and suppressing named
fields of an interpreted class. Instances are automatically modified.
- setIndex/0 and remIndex/0 set the class indexed or not indexed.
Instances are automatically modified.
Various tests:
- isClass/0 tests if the object is a class.
- isA/1 tests the membership of an object in an inheritance.
- isCompiled/0 and isIndexed/0 test if a class is compiled or indexed.
Garbage Collector:
- dumpTo/0 and dumpToMo/0 display information about the Object Table
and the Object Memory.
- go/0 runs the Garbage Collector.
- moFree/1 and toFree/1 indicate the number of free object references
and the number of free elements in Object Memory.
- searchObjref/0 shows where an object reference is used: in the
Prolog stacks, in the dictionary, in the records, or in the objects.
2.5 Graphic Development Environment
SP-Prolog offers a graphic development environment based on X-Window 11.3
which contains:
- windows dedicated to the session, trace, edition, system and
message display,
- an on-line help by predicates and themes,
- a set of menus, with an aid associated to the different functions,
- browsers to explore module, class and object contents.
The class browser enables the user to see the two parts of a class:
- the behavior of the class itself, and
- the behavior of the instances.
Each part contains the list of the defined named fields, the list of
imported predicates and used modules, and the defined predicates or methods.
The source code of predicates and methods can be displayed in a
dedicated panel.
The object browser is an easy way to examine the fields of an object and
to recursively browse the objects, structures and lists appearing in its
fields.
3. IMPLEMENTATION
3.1 Object Table and Object Memory
Different from Smalltalk-80, not everything in SP-Prolog + Objects has
to do with objects; in particular, managing predicate call or message
sending stacks is carried out by Prolog. Speed of message sending, field
accessing, Garbage Collector is not crucial.
Consequently, we have given priority to simplicity of implementation
in order to encourage extension possibilities.
The user manipulates the objects by means of tagged terms the type of
which is objref and the value of which is an object pointer.
This pointer designates a cell in the Object Table containing a pointer
to the physical implementation of the object in the Object Memory.
This indirection way via the Object Table is a little bit costly, but
greatly simplifies implementation of the Garbage Collector and of the C
language interface.
When the user has named his objects, a second indirection way appears,
but it remains negligible.
When the value of an object field is atomic, it is directly contained
in the field.
When a complex field is involved (structure, list or string), the
value is stored in the Object Memory, and the field contains the
direct pointer for this value. A complex field cannot be shared.
Here is an example of an object with complex fields:
array <<- new(3,O),
O <<- put_at(1,5),
O <<- put_at(2,f(1,"abc")),
O <<- put_at(3,"Prolog").
3.2 Garbage Collector
The Object Table is run like a list of free cells, chained together.
The Object Memory is run like a heap which increases until it is saturated.
The Garbage Collector is activated in three cases:
- Saturation of the Object Table,
- Saturation of the Object Memory during creation of an object,
- Saturation of the Object Memory during creation of a complex field.
During saturation, the Garbage Collector searches the Prolog zones where
object references may appear (Prolog resolution stacks, dictionary,
Prolog records), then it searches the living objects.
Object Table freed cells are added to the list of free cells.
The living objects are copied in a second Object Memory, with compression.
In cases where saturation appears when a complex C primitive is building
several objects, an object declared always living serves as a temporary
stack for C objects.
Carried out presently in a single pass, marking of living objects and
their copy should be carried out in two steps, in order to improve
the pinpointing of pointers manipulated during garbage collecting:
- First the Prolog zones,
- Then, afterwards, the Object zones.
3.3 Implementation Languages
SP-Object has been implemented by means of 3 languages: LLPAM (virtual
assembler for Prolog), C and Prolog. The distribution of the number of
code lines is as follows:
- LLPAM : 2600
- C : 8300
- Prolog : 1300
There are also 4600 Prolog lines for elementary tests of basic functionalities
and predefined methods, and about 500 lines added in the compiler.
The crucial primitives (message sending, access to fields, interpretation and
trace) have been written in LLPAM, in order to encourage execution speed.
All the basic primitives (Object and Class management, Garbage Collector,
predefined Methods) have been written in C.
Prolog has only been used for interface definitions between the
Prolog methods and their implementation in C, as well as for certain
utilities (object dump, acquisition and display of class inheritance).
We therefore believe that we have established a system combining
execution speed (LLPAM) and development flexibility (C and Prolog).
4 FUTURE WORK
4.1 Save and Restore of Objects
Primitives for saving in a file and restoring an object and all its
sub-objects or instances of a class are under development.
They will allow separate creation of files containing consistent sets
of data structured in object networks.
After saving, these objects should be restored and added to the objects
existent in memory.
In order to encourage saving and restoring speed, objects are saved in
the same format as they are managed in memory.
4.2 New Kernel Classes
A set of new classes should be provided:
- automatic management and linking of instances,
- creation of dictionaries and collection.
4.3 Connexion to OODBMS
Connection of an object oriented language to a persistent object management
system is natural.
We are presently studying various solutions:
- interfacing an Object Data Base, offering the management of
persistence, concurrent access, and objects distribution.
- coupling to a low level persistent object management system.
5 REFERENCES
[AILRI89] CESP Language Guide.
AI Language Research Institute, 1989.
[AKN86] H. Ait-Kaci, and R. Nasr.
LOGIN: A Logic Programming Language with built-in Inheritance.
The Journal of Logic Programming, 1986.
[Anj86] A. Anjewierden.
How about a Prolog Object.
Proc. Langages Oriente's Objet.
Bigre + Globule No 48, 1986.
[BC86] J.P. Briot and P. Cointe.
The OBJVLISP Model: Definition of a Uniform, Reflexive and
Extensible Object Oriented Language.
[BCFGM87] C. Bailly, J.-F. Challine, H.-C. Ferri, P. Y. Gloess and B.
Marchesin.
Les Langages Oriente's Objets.
Cepadues-Editions, Toulouse (France), 1987.
[Byt81] Smalltalk.
Byte, August 1981.
[Byt86] Object-Oriented Languages.
Byte, August 1986.
[CDE] D. Chan, P. Dufresne, and R. Enders.
PHOCUS: Prolog with Objects, Production Rules and Contexts.
ECRC Technical Report LP-21-02, Muenchen (WG), 1987.
[Chi83] T. Chikayama.
ESP-Extended Self-contained Prolog.
New Generation Computing, No 1.
OHMSHA, 1983.
[Chi84] T. Chikayama.
Unique Features of ESP.
Proc. International Conference on Fifth Generation Computer Systems.
ICOT, 1984.
[Chi84] T. Chikayama.
ESP Reference Manual, TR-044.
ICOT, Tokyo, 1984.
[CMNNT87] D. Colnet, G. Masini, A. Napoli, Y. Noiret, and K. Tombre.
Les Langages Oriente's Objets.
TR CRIN 86-R-077.
CRIN, Nancy.
[CN83] J. Cohen and A. Nicolau.
Comparison of Compacting Algorithms for Garbage Collection.
ACM Transactions on Programming Languages and Systems, October 1983.
[Coh81] J. Cohen.
Garbage Collection of Linked Data Structures.
ACM Computing Surveys, September 1981.
[CWB86] P. J. Caudill and A. Wirfs-Brock.
A third Generation Smalltalk-80 Implementation.
Proc. OOPSLA'86.
[DB76] L. P. Deutsch and D. G. Bobrow.
An Efficient, Incremental, Automatic Garbage Collector.
Communications of the ACM, September 1976.
[Dig86] Digitalk Inc., 1986.
Smalltalk/V, Tutorial and Programming Handbook.
[Don89] Ph. Donz.
SP-Prolog : Un Atelier Logiciel pour l'Intelligence Artificielle.
To be published in Proc. FORINCOM 89, Paris.
[Don89] Ph. Donz.
SP-Prolog: A truly industrial Prolog.
Bull SA, Knowledge Systems.
Private Communication.
[DRKG] Ph. Donz, T. Reix, E. Kerbaje and Th. Gandilhon.
SP-Prolog: Un Prolog industriel et inte'gre'.
Ge'nie Logiciel No 14, La Lettre Prolog.
EC2 Nanterre (France), 1989.
[Gal86] H. Gallaire.
Merging Objects and Logic Programming.
AAAI, 1986.
[GB85] A. Goldberg and D. Robson.
Smalltalk-80, The Language and its Implementation.
Addison-Wesley, Amsterdam, 1983.
[HC84] T. Hickey and J. Cohen.
Performance Analysis of On-the-Fly garbage Collection.
Communications of the ACM, November 1984.
[Ili87] H. Iline.
LAP : Un environnement Oriente' Objets en Prolog.
IIRIAM, Marseille (France), Private Communication.
[Kra84] Glenn Krasner.
Smalltalk-80, Bits of History, Words of Advice.
Addison-Wesley, Amsterdam, 1983.
[LD87] B. Lang and F. Dupont.
Incremental Incrementally Compacting Garbage Collection.
Symposium on Interpreters and Interpretive Techniques.
ACM SIGPLAN'87.
[LH83] H. Lieberman and C. Hewitt.
A Real-Time Garbage Collector based on the Lifetimes of Objects.
Communications of the ACM, June 1983.
[SB86] M. Stefik and D. G. Bobrow.
Object-Oriented Programming: Themes and Variations.
The AI Magazine, Winter 1986.
[SS86] L.Sterling and E. Shapiro.
The Art of Prolog.
The MIT Press, 1986.
[SP89] Bull SA.
SP-Prolog v2.1, Reference Manual.
[Sta86] E. Stabler.
Object-Oriented Programming in Prolog.
AI Expert, October 1986.
[Ung84] D. Ungar.
Generation Scavenging.
Proc. Symposium on Practical Software Development Environments.
ACM, 1984.
[Zan84] C. Zaniolo.
Object-Oriented Programming in Prolog.
Proc. IEEE Symposium on Logic Programming, 1984.
!! CUT HERE -------------------------------------------------------------------
-------------------------------------------------------------------------
Name: Tony Reix
Email: Tony.Reix@ec.bull.fr
Address: BULL, B.P. 208, 38432 Echirolles Cedex, France
Tel,Telex,Fax: (33) 76 39 75 00 ext. 7267 - 980648 F - (33) 76 39 76 00
-------------------------------------------------------------------------