Ernie Tello is a consultant, lecturer, and writer in the field of artificial intelligence. He can be reached at 1518 W Clift Dr., Santa Cruz, CA 95060.
The release of Turbo Prolog 2.0 has made clear Borland's intention to continue improvement of this product along two distinct directions: to make Turbo Prolog more suitable to conventional business applications and to bridge the gap between it and standard Prolog. Some major new additions are a new user environment, expanded internal databases, external Prolog databases, a new graphics interface, and a near-to standard Prolog interpreter.
What you notice first about Turbo Prolog 2.0 is the difference in the user interface. The function key assignments have been changed to some extent. Two convenient new features are the Window zoom key (F5) and the Next window function key (F6) which enables you to cycle around the windows in a predetermined order. The most drastic change is that the whole interface is completely redefinable. And finally, the key assignment screens allow you to assign two different key commands to every function.
The Borland-style interface gives the appearance of two editors being copresent. You can use the regular editor for one module of your program, and then call up the auxiliary editor to write documentation or to work on other modules. Although this provides some of the advantages of having two simultaneous editors, in actuality the same code is being executed by both. This is apparent when you try to use the Next key to get from one editing window to another, but you can't. The main advantage here is the convenience of keeping one file loaded in the main editor while retaining the ability to work on other files without unloading the auxiliary editor.
Two important changes have been made in the Turbo Prolog database system. The internal databases now allow multiple-named internal databases in a single application. A new type of Prolog database, a database on disk that supports full random access, can now be created. The option of creating multiple-named databases provides an interesting form of data partitioning in Turbo Prolog. To support this feature, the assertion and retraction functions have two different forms: operating as before, to support the old syntax; and with an additional argument the name of the database.
When a named internal database is declared, you just declare the database predicates. Facts can be added to an internal database in four different ways: asserting them in the clauses section of a program, asserting them at run time, loading them from a disk file, and by using the readterm predicate (explained later). The save and consult predicates can now take an additional argument which is the name of one of the internal databases.
The expanded internal databases have some potentially powerful uses. These databases can be used as a form of partitioned working memory to solve complex problems. This feature adds the potential to write programs that operate like forward chaining systems. This means that assertion and retraction can occur in powerful ways within distinct memory areas.
Another important advantage of the multiple databases is the ability to do complex disk operations interactively while programs are running. The fact that files may be saved and loaded into named data areas provides an important form of modularity that allows for creative application development. For example, a program can be written to read disk files into named database areas, perform inferences that result in new assertions added, and then save the expanded files to disk. Each time the program is run, it can be operating with more expanded databases that enable additional inferences to be made.
This type of programming is much different from the pure Prolog advocated in many of the traditional Prolog programming texts. According to the traditional style of programming, assertion and retraction is performed sparingly. Turbo Prolog is far from being the purists type of Prolog. Although it is a Prolog with idiosyncrasies, compromises, and tradeoffs, the style of programming that can work effectively in Turbo Prolog is not the same as for standard Prolog.
Turbo Prolog provides a means to keep internal databases on disk. The documentation shows how user-defined predicates can be written that do this and even how to use index files to record the position of facts m the data file.
The addition of external database support to Turbo Prolog means that the size of applications is no longer confined to the space allowed by internal memory. One of the main limitations of Turbo Prolog has been the size of programs that can be written. With the external database capability, valuable memory no longer need be used for storing factual data but can now be done with random-access files. These databases are not the usual kind of field and key databases but rather Prolog databases.
A main difference between internal and external databases is the facilities that external databases provide. External databases are stored in binary format in chains of like terms, and B-trees can be used when the databases need to be sorted. Access is provided to external databases through database reference numbers. Predicates are provided that can manipulate whole databases, chains, and terms. The real difference between internal and external databases, therefore, is the type of access available for each.
A useful way of combining internal and external databases might be to use internal databases for storing results obtained by querying external databases. At first the result stored there can be temporary. But by making other inferences, further assertions of a more permanent type can be made into a different internal database which can be saved to disk if desired. External databases are more like conventional databases; they have many accessing functions and features that make large systems of records maintainable. Once you become familiar with using the two types of Turbo Prolog databases, various techniques will allow you to design the optimal mix of the two for given applications.
Borland has introduced its BGI (Borland Graphics Interface) into Turbo Prolog. Previous versions of the language had graphics but not on this level of sophistication. Turbo Prolog now has 70 graphics-related predicates. This graphics system includes support for defining viewports, which are windows in the graphics mode. As with text-mode windows, viewports show only the part of a graphic image that falls within its borders. Perhaps the nicest part of the graphics interface are the drawing predicates that are provided. With setlinestyle you can specify the thickness and visual style of the lines drawn. Built-in predicates are included for drawing shapes such as circles, ellipses, rectangles, polygons, arcs, and pie slices. For business purposes, predicates are provided for drawing bar charts (including three-dimensional bar charts). Predicates are also supplied for performing various types of fills.
Borland's Prolog interpreter comes closer to supporting standard Prolog than the compiled language has up to now. None of the I/O and debugging predicates of standard Prolog are supported, since Turbo Prolog already has its own. A surprising number of the standard features are present, including those for AI purposes. The interpreter comes in Turbo Prolog source code and is run like any other application in Turbo Prolog.
The interpreter comes with its own built-in editor that works essentially the same way as the main editor in the development environment. One important difference is that if a file has been loaded into the interpreter, it automatically appears in the editor when the editor is called up. This handy feature means that you can conduct an interactive session, call up the editor at any time, and inspect and edit the current contents of Prolog memory to save it to disk.
The Prolog interpreter included as a program in this version is closer to Clocksin and Mellish than it is to Turbo Prolog. Since the dialect is different from Turbo Prolog, working with the two different dialects could be more trouble than it's worth.
I don't agree with that assumption. I find myself applying at least two rather important uses to this interpreter. One is trying out ideas that I will later import into the compiled dialect. The advantage here is that you don't have to make type declarations first but can start coding right away without any preliminaries. This is not for large programs, mind you, but rather for small experimental "laboratories "for ideas. With the compiled language, you're better off making type declarations as you go along, rather than all at once.
The second use of the interpreter is for writing things that you cannot write in compiled Turbo Prolog. If need be, you can even try to embed the interpreter in an application to run that code.With this release of the interpreter, the tradeoff between I/O and the need for meta-predicates and run-time binding has been overleaped to some degree.
An important addition with this version is support for a two-way interface with outside languages. Previously you could call C functions from Turbo Prolog if those functions followed the rules. Now you can do the opposite as well. Predicates can be written and compiled and then called from C programs. The advantage here is that you can write an advanced database system in Turbo Prolog and then embed this in a program written in another language. You can, thus, take advantage of something not available to you in Turbo Prolog (such as some code that you or another developer might have already written).
Those programmers who have applications written in the old version of Turbo Prolog should have no problem making them run in version 2.0. I tested a large program written in the original Turbo Prolog, and it ran without any problems.
The main limitation of the language now is the size of programs that can be written. It's now becoming state-of-the-art for programming languages to take advantage of the protected mode of the Intel 286 and 386 processor series. It is only natural to expect that Borland will wish to stay in pace with the industry and produce a protected-mode version of Turbo Prolog that will be able to run in the extended memory areas of 16 Mbytes and higher.
Another important direction that Borland could take is to make the compiler support the version of Prolog implemented in the interpreter. Those programmers who are interested in the features of Prolog that make it suitable for Al applications would be able to enjoy the fast running speed of compiled Turbo Prolog code, as well as to take advantage of the wide range of I/O capabilities provided in version 2.0 and in the Toolbox. Combined with the ability to run in protected mode, these would represent an unbeatable combination of features for a Prolog implementation.