next up previous index
Next: Porting Programs to plain Up: Porting Applications to ECLiPSe Previous: Porting Applications to ECLiPSe   Index

Subsections

Using the compatibility packages

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: 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:

Compiler versus Interpreter

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.

Name clashes with global ECLiPSe builtins

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 up previous index
Next: Porting Programs to plain Up: Porting Applications to ECLiPSe Previous: Porting Applications to ECLiPSe   Index

1999-08-06