Spring cleaning coming

The development of the current generation of Logtalk, 2.x, began on January of 1998. At that time, the ISO Prolog Standard (Part 1: General Core) was only three years old. Thus, accepting and dealing with the lack of compliance of most Prolog compilers with the standard was a sensible choice.

Back to the present. The ISO Prolog Standard is now 15 years old. Compliance with the standard greatly improved for some but not all Prolog compilers. Trying to keep minimal Logtalk compatibility with some of the existing Prolog compilers is no longer feasible. In fact, keeping compatibility with the most problematic Prolog compilers (as far as standard-compliance goes) is working as an anchor, slowing Logtalk development and preventing improvements and implementation of new features.

Some of the most problematic Prolog compilers (again, from the point-of-view of standards compliance) are (to the best of my knowledge) no longer being developed. Other Prolog compilers, actively maintained today, decided to ignore the current official and de facto standards. A few, such as IF/Prolog, provided good standard compliance but have been apparently discontinued by their developers.

I plan to ditch Logtalk compatibility with the following Prolog compilers in the upcoming 2.39.0 release: ALS Prolog, Amzi! Prolog, BinProlog, GNU Prolog, IF/Prolog, JIProlog, K-Prolog, LPA MacProlog, LPA WinProlog, Open Prolog, MasterProlog, PrologII+, Quintus Prolog. This may seem like a long list but I suspect this decision will have no consequence for most (if not all) Logtalk users. If If you think it is still worth to support some compiler in this list please contact me as soon as possible.

UPDATE: added GNU Prolog to the list of no longer supported compilers. Support for this compiler will be restored as soon as it implements the ISO Prolog standard directive multifile/1.


2 Responses to “Spring cleaning coming”

  • Parker

    I imagine a significant part of the development of Logtalk has been building a compatibility layer across all the various Prolog systems. The OO system (Logtalk proper) then sits on top of this layer.

    Dropping several Prolog back-ends is likely to result in a significant part of this compatibility work being lost. This is a shame as there are many years of work and a great deal of expertise that will go down the plug hole.

    So I wonder whether it isn’t worth splitting Logtalk and the compatibility layer into two separate projects. The new project, e.g. PPCL (Paulo’s Prolog Compatibility Layer), would provide people wishing to write portable code a set of libraries that allow their code to work on a large number of systems. Some people might be interested in Prolog portability without having to buy into a full OO language. They might even contribute to the project.

    Logtalk in turn could make use of this library (even if it doesn’t work across on all Prolog implementations).

    It strikes me as significantly better than just abandoning the code.

    Just a thought,
    Parker

    • Paulo Moura

      On the surface, dropping compatibility for those Prolog back-ends may seem a radical decision. In reality, the majority of those Prolog compilers are dead and are no longer supported. Even if you can get a copy, you will most likely have trouble running them in modern operating-systems. Maintaining compatibility with these outdated (and not up to current standards) compilers serves no useful propose and prevents Logtalk from moving forward. Earlier, compatible Logtalk versions are still available if anyone wishes to try it using those compilers. Note that the corresponding config files are included in the current Logtalk version, although in an “unsupported” directory.