Amzi! Prolog consists of five primary tools, two libraries and six file types. The tools are:
Throughout this manual both the full name and generic names of the tools are used. For command-line environments, the generic names are also the names of the commands themselves (e.g. acmp.exe is the name of the compiler). For GUI-window environments, the tools are accessed from menus and tool bars.
This section briefly introduces the Amzi! tools and file types.
Normally Prolog code is developed using a Prolog interpreter, also called a "listener." The listener directly executes source code, which is stored in a plain text file (.pro file), or typed in directly at the ?- prompt. So developing an interpreted Amzi! Prolog module consists of these steps (the corresponding IDE commands are given in parentheses):
The Amzi! debugger is used to find and identify errors. It works on interpreted source code. The debugger can only be invoked from, and used within, the listener. In order to step through code, you need to consult the source code form of the module.
The Amzi! listener differs from other Prolog listeners because you can consult both source code files and compiled object code files. In fact, you can intermix compiled and interpreted code in the same application and listener session. This allows you to keep code under development in source form, and debugged code in compiled form.
The Listener is the heart of the Amzi! development tools. It is where you develop, test and debug your Prolog code.
Interpreted code is normally used only for dynamic data, debugging and experimentation. Once a module is completed, it is usually compiled into an object module (.plm file). No source code changes are required before compiling.
The development cycle is extended with the following steps to compile working modules, while keeping modules under development interpreted (in source form):
Compiling has a number of advantages. Compiled code runs at least 10 times faster than interpreted code. Compiled programs that have recursive calls will run longer before exhausting stack and heap resources. Finally, predicates in compiled modules can be hidden, making it easier to build large, multi-file applications.
The object file contains instructions for a Warren Abstract (Prolog) Machine (WAM). The WAM is the core of Amzi! Prolog, it is also called the Amzi! runtime, and is provided in both executable and library forms. The same Prolog object file (or source file) can be run on any version of the Amzi! runtime.
Once an application has been debugged, the object files (.plm) are linked into a single executable load module (.xpl file) that can be embedded in a C/C++, Java, Visual Basic, Delphi, Web Server or other program, or run as a standalone program.
The linker automatically links in a copy of the standard Amzi! library alib.plm into each .xpl file. You may also want to link in a library such as the list utilities library LIST.PLM.
An example of an executable load module is the file alis.xpl in your distribution files. It is the listener, which is itself an Amzi! Prolog application.
The tools just described are all available from the operating system command line using the specified program names. The tools are also gathered together under a single Integrated Development Environment (IDE) for Windows.
The IDE allows you to run the listener with its debugger, the compiler, the linker and the runtime (see below). It also includes an editor and the ability to define projects (PPJ files). Projects provide a convenient means to organize multi-module applications. There are two IDEs: wideW supports the full Unicode character set, and wideA the ASCII character set.
The Amzi! runtime executes a Prolog load module (.xpl file) created by the linker. A distributable Amzi! application minimally consists of a runtime and a load module.
The final steps, then, in building a Prolog application are:
Separate runtimes are provided for each supported environment. arun is the .exe form of the runtime and allows for standalone Prolog application development. The dynamic library forms of the runtime allow for embedding the Amzi! runtime in other languages.
An Amzi! application must have one .xpl file, and only one .xpl file. However, that .xpl file can consult as many other source files (.pro) and compiled object files (.plm) as needed.
An Amzi! application might also include an initialization file (.cfg file) which specifies the sizes of the heaps and stacks, and gives you control over other operational parameters of the Amzi! runtime. The initialization (.cfg) file bears the same name as the load (.xpl) file. One file, amzi.cfg, can be used to set system-wide defaults. If there are no .cfg files then default values are used.
The Amzi! runtime is a full Unicode implementation. This means that, internally, all strings are stored as wide (Unicode) character strings. Further, Prolog source text can be stored in Unicode format, enabling the inclusion of Unicode characters directly in Prolog programs.
The Amzi! runtime is also embodied in dynamic/shared libraries which can be linked into and called from a variety of languages and tools. Like arun, these libraries execute an Amzi! load module (.xpl file).
The programming interface to the Amzi! runtime is called the LSAPI. It provides over 50 functions that, in large part, mimic the functionality of the Prolog listener. You can load source and object code, issue queries, map the results of those queries to variables, assert new facts, build/decompose lists and structures and more.
The Logic Server API is provided as a C interface, a C++ class library, a Java Class, a Delphi Component, a Visual Basic definitions module and a general purpose interface (for other non-pointer-based languages).
Further, the Logic Server API lets you add your own predicates (functions) to Amzi! Prolog, thereby extending the Amzi! language implementation with your own C/C++ code. An example of this might be functions to access your database.
The Amzi! Logic Server also supports multiple, simultaneous invocations. Multiple engines are implemented simply by allocating a new Logic Server object. This can be done through either the native LSAPI interface, the new C++ Logic Server class, or any of the environment specific lsapis, Delphi, VB, or Java.
Next, we recommend you run through "A Quick Tutorial" which follows next. If you plan to embed Prolog code in other applications, you can follow the tutorial for the appropriate 'hello' samples which are described in the Logic Server API section.
There is also a detailed introduction and reference section for each of the tools described above.
Copyright ©1987-2000 Amzi! inc. All Rights Reserved.