ISO Prolog Core

Jan Burse, created Oct 13. 2010 Implementing a Prolog interpreter against the ISO core standard was a very rewarding experience. We had already implemented some Prolog interpreters for research purposes but we never tried before to match it against the ISO core standard. Since the ISO core standard has gained acceptance over the last years we felt it beneficial to fit one of our Prolog interpreters to this standard. We have not yet reached full compliance but would like to share some of our experiences. The ISO core standard had some educational effect on our own development. We started with adopting the exception handling and the many exceptions that are found in the standard. We appreciated especially the definition of the exception base classes which allowed us applying the concept also to predicates not found in the ISO core standard. We were also able to map the Prolog exceptions to the exceptions of our implementation language Java. The exceptions save us an error code result parameter and we find an efficient support for them in the Java host language. We could further improve our syntax handling by following the ISO core standard more closely. The standard is very modern in that it is character based and not byte based. An issue with the ambiguity of operators has been circumvented in our previous implementations by aseparate data type for character sequences. We now follow strictly the approach that atoms may also serve the purpose of character sequences and have abandoned the separate data type. Further our syntax is now able to escape the functor reading of an operator as defined in the standard. Unfortunately the standard leaves open the parts of the Prolog system that are responsible for consulting Prolog texts and the parts that might serve as an interactive top level loop. Also the debugging of Prolog code is not specified and we also do not find some information on dealing with compiled and non-compiled predicates. So to archive a certain acceptance we had to draw from another sources. We could find information on consulting, the top level and debugging in the DEC-10 manual, a former de-facto standard for Prolog and a precursor of the ISO core standard. The ISO core standard does not provide a receipt for an efficient implementation of a Prolog engine. The logical operators and the database handling are astonishingly precisely described. The given examples can be used to validate an implementation. But the emphasis is not on any non-functional requirements. For example we find a definition of the cut which is based on removing choice points only during undo. Modern Prolog engines typically separate the choice points from the variable bindings so as to allow an early removal of the choice points. Although the ISO core standard very well serves the purpose of a functional specification, we have a strange feeling against it. For example the semi-formal appendix is quite verbose and does not really give an additional value. Further it might have been more wisely to include modules already in the core. And then to dispose totally with all the stream and arithmetic built-ins. This might reduce the footprint of the core and would free it from repeating specifications that are found elsewhere. Via the module concept the stream and arithmetic built-ins could then come separately. More important we feel the lack of an API orientation in the ISO core standard a big drawback. An API orientation would mean a shift of viewpoint. The ISO core standard would not deal anymore with a Prolog system, but with a Prolog component that has to co-exist with other components. The API would define the required call-in and the call-out interface of the Prolog engine. This would allow a much broader applicability of Prolog in industry. Prolog engines could interact with applications in a plug and play fashion. This would fertilize the competition and secure investments into applications that make use of Prolog.