Next: Porting Programs to plain
Up: Porting Applications to ECLiPSe
Previous: Porting Applications to ECLiPSe
  Index
Subsections
The ECLiPSe compatibility packages are the fastest way to get a
program running that was originally written for a different system.
The packages contain the necessary code to make ECLiPSe emulate
the behaviour of the other system to a large extent.
Compatibility packages exist for:
- ISO Standard Prolog, use use_module(library(iso))
(cf. appendix A.5)
- C-Prolog, use use_module(library(cprolog))
(cf. appendix A.6)
- Quintus Prolog, use use_module(library(quintus))
(cf. appendix A.11)
- SICStus Prolog, use use_module(library(sicstus))
(cf. appendix A.13)
Note that every package makes use of the preceding ones.
To run SICStus applications, it is often enough to use the quintus mode.
The source code of the compatibility packages is provided in the
ECLiPSe library directory.
Using this as a guideline, it should be easy to write similar packages for
other systems, as long as their syntax does not deviate too much
from the Edinburgh tradition.
The following problems can occur despite the use of compatibility packages:
If your program was written for an interpreter, e.g. C-Prolog,
you have to be aware that ECLiPSe is a compiling system.
There is a distinction between static and dynamic predicates.
By default, a predicate is static. This means that its clauses have to be
be compiled as a whole (they must not be spread over multiple files),
its source code is not stored in the system,
and it can not be modified (only recompiled as a whole).
In contrast, a dynamic predicate may be modified by compiling or
asserting new clauses and by retracting clauses.
Its source code can be accessed using clause/1,2 or listing/0,1
A predicate is dynamic when it is explicitly declared as such or when
it was created using assert/1.
Porting programs from an interpreter usually requires the addition of
some dynamic declarations.
In the worst case, when (almost) all procedures have to be dynamic,
the flag all_dynamic can be set instead.
Suppose you want to define a predicate named date/1, which conflicts
with the ECLiPSe builtin called date/1.
In this case the compiler will produce one of the following messages
warning: redefining a system predicate in date / 1
*** trying to redefine a procedure with another type: date / 1
depending on whether the definition or a call to the predicate
was encountered first by the compiler.
Both can be avoided by declaring the predicate as local.
This declaration must be given before the first call to the predicate:
:- local date/1.
p(Y) :- date(Y).
date(1999).
Note that the date/1 builtin is now hidden by your own definition,
but only in the module where you have redefined it5.1.
In all other modules, the builtin is still visible.
The same holds for the redefinition of protected predicates,
see also section 3.7
and appendix E.
Next: Porting Programs to plain
Up: Porting Applications to ECLiPSe
Previous: Porting Applications to ECLiPSe
  Index
1999-08-06