I’m currently porting John Fletcher’s XML Parser to Logtalk. I’m also considering porting P-FLAT, Artur Dias and Michel Wermelinger’s toolkit for formal languages and automata theory. The ports are easy although more time consuming that I wished for. Given that Logtalk assumes a ISO Prolog compliant compiler underneath, the original Prolog programs must have all proprietary Prolog calls replaced by their ISO counterparts; that’s the price you pay for the broad compatibility of Logtalk with most Prolog compilers in use today.
It’s clear to me, given these current and past port exercises, that broad sharing of Prolog code between implementations suffers from both weak ISO Prolog standards and lack of knowledge of the current standards by Prolog programmers. Work on improving the current standards is underway but also undermanned. Lack of knowledge of the current standards can be partially explained by the simple fact that the ISO documents are only available for a fee (there is also a nice book on the ISO Prolog standard by P. Deransart, A. Ed-Dbali, and L. Cervoni). Another possible explanation is that most Prolog programmers do not feel a need for writing portable code. Or simply lack the perception that their code will not run and, in some cases, will not even compile, when using another Prolog implementation. This is as much as a problem with programmers as a problem with the Prolog language itself. People working with Java, Python, C#, or PHP do not face the kind of compatibility problems that plague Prolog programming.
We have a very rich Prolog ecosystem with more than two dozen implementations currently available. Even if we count only the most popular ones, their number is still close to a dozen. However, Prolog is nowadays little more than a niche language. Lack of code sharing means that Prolog programmers cannot bootstrap their applications without being trapped in some proprietary implementation, even for basic tasks. Lack of libraries and bindings for popular APIs makes choosing Prolog as an industrial tool a risky proposition, despite all the advantages when compared with other languages. Is the Prolog future bleak? I like to think that you and me can make a difference. How? By demanding better ISO Prolog compliance from Prolog implementers, by working with our local standards committee, by regularly rotating Prolog compilers when programming. Current standardization efforts include DCGs, Globals, and Threads. A revision to the core standard is also underway, fixing typos, omissions, and hopefully adding some missing built-in predicates that should have been there from the start. If you currently have an itch that needs scratching, why not find other programmers facing the same problems (Prolog mailing lists and the comp.lang.prolog newsgroup are good places to start) and write a draft proposal?