Paulo Moura
Universidade de Beira Interior
Portugal
Editor:
Roberto Bagnara
I've been asked by Roberto Bagnara, "implementation area editor" for
this newsletter, to write an article on Prolog portability
problems
and solutions. This would be a followup to my first newsletter
article, published on May 1999. However, the present text turned out
to be more political than technical. For a good reason. Six years
later, what has changed? Not much, I'm afraid. Sure, several Prolog
compilers, specially open-source ones, improved their compatibility
with the Part I of the ISO Prolog standard. However, there is still
no
certification process in place or widely accepted conformance tests
that a programmer may use and rely on when porting its Prolog
applications.
Part I of the ISO Prolog standard can be considered a minimalist
standard. Considering the amount of work needed to conciliate often
disparate views and reach consensus, problems so typical of
standardization processes, that is understandable. Nevertheless, the
current standard is too minimal to prevent many of the portability
problems we face today, due to the diversity of solutions to perform
even the most basic tasks such as consulting Prolog code or accessing
the underlying operating system. This is compound by another problem:
lack of an widely accepted way of extending the core language in a
controlled way. That is, namespaces, which can be implemented using
either modules or objects. Namespaces is a key feature in the
implementation of a rich set of Prolog predicate libraries. Mature,
wide-covering libraries are instrumental in language adoption. Where
would be Java without its APIs? In 2000, ISO published a specification
for a Prolog module system. Problem is, the proposed module system is
incompatible with current practice and, as such, is basically being
ignored by almost all Prolog implementors.
As of today, no revision of the Part I of the ISO Prolog standard was
been published, trying to re-conciliate it with current practice. The
1999 standard does not include widely used predicates that most
people, programmers and vendors alike, would expect to be there.
Examples are predicates such as compare/3, callable/2, retractall/1,
or sort/2, which are built-in predicates on almost all Prolog
compilers. There are also some strange omissions such as a numbervars/1
write option with no specification for a numbervars/3 predicate.
The set of ISO specified predicates is to small and limited for many
applications, especially for those that need to interface with the
operating-system, other languages, GUI toolkits, or the Internet. The
lack of standard (or de facto standard) libraries means that
portability of Prolog applications is often limited to one (running
our Prolog code using a single compiler but on several operating
systems may raise portability problems on its own) or just a few
compilers. For those of us following the recent history of the rise
and fall of several Prolog compilers, this is a scary prospect when we
try to sell a Prolog solution to an industry customer or even to
deploy it in an academic environment. This state of affairs also leads
to the lack of skilled human resources as logic programming struggles
to survive in academia curricula under the pressure of better
marketed, more mature, standardized, and widespread programming
languages and programming paradigms.
Meanwhile, Prolog implementers have been busy improving and adding
useful features to their compilers. These features allows Prolog to
keep a foothold on some niche markets (e.g., constraints) or to compete
in more level terms with other programming alternatives for innovative
applications (e.g., semantic web). I will focus here on only two of
such features: threads and Unicode. A number of Prolog compilers
already include support for multi-threaded programming. Some
others
are being heavily hacked to become fully multi-threaded. In most
cases, the multi-thread support is similar enough such that the
corresponding built-in predicates and semantics are likely candidates
for standardization. Now, rather than later, would be a good time to
try to reach some common ground, before another useful Prolog feature
further contributes down the road to the balkanization of the language
implementations. The same goes for Unicode. A few Prolog compilers
already support source files using Unicode encodings. Finally! Problem
is, each one does it in its own way. Some time ago, I have written a
Logtalk example that contains a table of "Hello world!" messages in
nine different languages, including Greek, Simplified Chinese,
Russian, and Korean. Unfortunately, this particular example only runs
on one of the Logtalk supported Prolog compilers. The idea that Prolog
programmers all around the world should limit themselves to using
ASCII in their programs is plain ridiculous. In my personal case, I
want to be able to use accented characters in my code without
resorting to tricks and without fearing my applications break down
when using some other Prolog compiler on a different operating-system.
Strong standards go a long way in minimizing portability problems. In
turn, they can lead to mature libraries, bootstrapping application
development through code reuse. It is important to stress that Prolog
standardization is, above all, a community problem, far behind the few
people with the resources and the opportunity to be directly involved
in the ISO standardization committees. As such, it needs to be
community-driven. Ignoring current practice and failure to seek and
gather feedback from users in the draft stages of future Prolog
standards are two errors that must be avoided. There are available
today some wonderful web-collaboration tools. Let's put them to good
use.