Is the ISO Prolog standard taken seriously?
Roberto Bagnara
the following article has been submitted for publication
to the Newsletter of the Association for Logic Programming.
It is meant to solicit discussion in the community.
Since I believe the subject is an important one, I am posting
the article also here. Please, feel free to redistribute it
as you like.
Have a great 1999,
Roberto
--
Roberto Bagnara
Department of Mathematics, University of Parma, Italy
http://www.di.unipi.it/~bagnara/bagnara.html
mailto:bag...@di.unipi.it
---------------------------------------------------------------------
Is the ISO Prolog standard taken seriously?
===========================================
Roberto Bagnara
Department of Mathematics
University of Parma
Via M. D'Azeglio 85/A
I-43100 Parma
Italy
E-Mail: bag...@di.unipi.it
In Short
--------
During the development of a CLP multi-language software tool I
discovered that the ISO Prolog standard is essentially disregarded.
This happens even for the most widespread and influential Prolog/CLP
implementations, even in their most recent versions, and even if we
look at syntax only. For instance, let us take X-Prolog to range
over "SICStus Prolog 3.7.1", "SWI-Prolog 2.8.1", "BinProlog 5.75",
"you name it".
Then it appears that:
1) an ISO Prolog program is not an X-Prolog program;
2) an X-Prolog program is not an ISO Prolog program.
It also seems that, even in most recent versions, choices have been
made that will make future conformance to the standard very difficult,
if not impossible at all. In other words, features that go openly
against the standard are not even deprecated in the documentation of
most systems. Users are thus encouraged to use these features. They
will write code using them. Who will then dare to break backward
compatibility?
For these reasons, I think I can give an answer to the question in the
title of this writing: no, generally speaking, the ISO Prolog standard
is _not_ taken seriously (there are exceptions, of course: for
instance, the developers of B-Prolog appear to seek for standard
conformance).
Another question naturally arises, and this is the question that urged
me to write the present note:
Is the ISO Prolog standard _to be_ taken seriously?
I read comp.lang.prolog regularly, I subscribed the "users" mailing
list for several major Prolog programming systems, and I regularly
visit the WWW sites dedicated to logic programming. But I have never
seen somebody complaining because some Prolog vendor/provider was
ignoring the standard. So, unless something important has escaped
my attention, the above question is legitimate.
After all, a standard that nobody cares about, in practice,
does not exist.
With this note I intend to solicit opinions from everybody in the
community: a question like this must not pass under silence and
an answer, any answer, can save the time of many people.
Prologue
--------
The experience I am reporting here began this summer, when I started a
major step in the development of China, a Prolog/CLP data-flow
analyzer. The objective of this step is ambitious: to stop toying
with more or less artificial and/or small and/or ad-hoc and/or hacked
example programs. Analyzing real programs in really implemented
(i.e., not idealized) languages is, in my humble opinion, the only way
to conduct a serious experimentation of the ideas and techniques
developed in the field of data-flow analysis of (constraint) logic
programs.
China was already parametric with respect to the particular kind of
analysis to be conducted. What remained to do (and still largely
remains to be done) was to support the implemented languages _as they
are_. By this I mean, real syntax, real built-ins (i.e., all of them),
plus all the other features: modules, libraries, foreign language
interfaces and so forth. The list of languages _more or less_
supported by China is now: SICStus Prolog, SICStus CLP(B), SICStus
CLP(FD), SICStus CLP(Q), SICStus CLP(R) (in the future this
distinction will be removed and there will be just one SICStus),
SWI-Prolog, BinProlog, WAMcc Prolog, WAMcc CLP(FD), WAMcc CLP(FD, S),
B-Prolog, Monash/IBM CLP(R), RISC-CLP(Real). In addition to these
actually implemented languages, China supports (more or less, in the
present state) another language: ISO Prolog.
The connection of this story with the subject of this paper is the
following: the development work outlined above has been and is a pain,
a big pain indeed.
The difficulties I am experiencing will have to be faced by anybody
working in software tools for logic programming. Moreover, the lack
of such tools is, in my opinion, one of the biggest problems of LP.
Troubles, Troubles, and Again Troubles
--------------------------------------
The things that make supporting the real languages a formidable task
are almost countless. Just to list a few: incomplete documentation,
non adherence of the actual systems to the documentation, different
syntax, different built-ins, different semantics for the same
built-ins, different module systems, different foreign language
interfaces, different kinds of basic types like integers and floats.
In what follows I will address only one of these problems, the most
basic one: syntax.
If an agreement cannot be found on such an elementary issue it is
useless to discuss about the semantics of built-ins and on, say, the
module system, language-independent arithmetic (ISO/IEC 10967) and so
forth.
Of the above mentioned languages only SICStus Prolog, SWI-Prolog,
BinProlog, and B-Prolog seem to be regularly maintained. In the
sequel I will concentrate on SICStus Prolog only for the following
reasons:
1) I know it much better than I know other systems;
2) I believe it has a wide user base;
3) people has to pay for using it, even in universities. (*)
In no way this choice implies that, as far as ISO conformance is
concerned, SICStus Prolog is worse than other systems. And this simply
because it is not true.
A reader of a previous version of this writing suggested that I should
check all the available Prolog systems for ISO conformance.
Unfortunately, this would be too much work and it would also require
the purchase of several licenses. The standard is more or less freely
available: if some Prolog vendor/provider steps forward and says
"hey, my Prolog is ISO conformant", then I will be very happy.
The objective of this writing is not to decide who is better, but to
see whether the community considers standardization important or not
(I personally consider it _very_ important).
[* For those who may question the relevance of (3): blaming a
volunteer that donates his software for not taking the ISO standard
into consideration is ridiculous. One donates what is willing to
donate. Things are different when vendors are considered. In this
case I can well imagine a customer complaining because the product he/she
is paying for is more or less violating an international standard he/she
presumably cares about.]
Syntax: SICStus Prolog versus ISO Prolog
----------------------------------------
The following is quoted from the "SICStus Prolog User's Manual",
release 3.7, October 1988:
SICStus Prolog complies in spirit, if not in detail, with the Draft
International Standard ISO/IEC 13211-1 (PROLOG: Part 1--General
Core). In particular, SICStus Prolog does not offer a strictly
conforming mode which rejects uses of implementation specific
features. Minor deviations also concern e.g. the syntax, the
arithmetic functions, and the error system. To aid programmers who
wish to write standard compliant programs, built-in predicates that
have a counterpart in the ISO Prolog Standard are annotated with [ISO]
in this manual, where appropriate with a comment clarifying the
difference between the SICStus and the prescribed ISO Prolog versions.
This is all what is said about the ISO standard. The user is not told
what the minor syntactic deviations from ISO Prolog are (and similarly
for the arithmetic functions).
A deviation that is all but minor is due to the following: in ISO
Prolog an operator cannot immediately follow another operator. Thus a
goal of the form X = '>' is not ISO Prolog (I have found similar goals
in several real programs). In ISO Prolog one has to write X = (>)
instead (bracketing allows an operator to be treated like an ordinary
atom).
Looking at this simple example the problem would not seem so
serious. Consider the following one. SICStus CLP(FD) defines '!' as
an operator. Namely, in SICStus CLP(FD) the declaration
:- op(600, xf, '!').
is in effect. This implies that a SICStus CLP(FD) clause of the form,
say,
p :- !, q.
is not valid in ISO Prolog, standing the declaration of '!' as an
operator ('!' and ',' are both operators, and thus one cannot
immediately follow the other). In order to make it conformant one
would have to write
p :- (!), q.
but does people want to write cuts this way?
So the choice (and confirmation even in the last release) of '!' as an
operator was an unfortunate one, from the point of view of standard
conformance.
Up to now we have seen a couple of examples whereby, syntactically
speaking, a SICStus Prolog program is not an ISO Prolog
program. However, the reverse statement also holds.
Consider escape sequences. In SICStus Prolog 3.7.1, you have:
| ?- name('abc\x20\def', X).
X = [97,98,99,32,127,101,102] ?
yes
while with an ISO-conformant system you would get
| ?- name('abc\x20\def', X).
X = [97,98,99,32,100,101,102] ?
yes
The problem stems from the fact that, in SICStus, an hexadecimal
escape sequence is defined (on page 402 of the manual) by (+)
\xCD the character code CD (two hexadecimal digits)
while ISO specifies
hexadecimal escape sequence (* 6.4.2.1 *) =
backslash char (* 6.5.5 *),
symbolic hexadecimal char (* 6.4.2.1 *),
hexadecimal digit char (* 6.5.2 *),
{ hexadecimal digit char (* 6.5.2 *) },
backslash char (* 6.5.5 *) ;
Note the trailing backslash required by ISO: SICStus will not accept
it as part of the hexadecimal escape sequence, and will interpret
"\d" as a (non standard) control escape sequence for delete (ASCII 127).
It is clear that the above definitions of hexadecimal escape sequence
are not compatible. In other words, a SICStus user may have surprises
when switching to an ISO-conformant system. Similarly, a program written
for ISO Prolog can be interpreted by SICStus as a different program.
[+ Indeed, SICStus 3.7.1, the latest version, will accept just
anything. For example, the query X = '\xzz' gives the answer
X = 'S'. This is the kind of "feature" that is able to transform
a simple typing mistake in a week of frustrating debugging work.]
Things LP users should take into account
----------------------------------------
No Prolog vendor/provider can guarantee that his system will continue
to be supported forever, or that it will be able to take advantage of
future processing devices, or that it will be conveniently ported to
other platforms, or anything like that. Usage of non-standard
features of the implemented systems is thus a risky operation. A
standard that is not only on paper is on the interest of users. It
allows them not to be tied to any particular vendor/provider, it
provides a whole lot of good, complete documentation (the lack of
complete documentation is one of the problems of most LP systems), it
greatly improves portability, it enables the use of tools coming from
different sources, it brings to the development of better software
environments, and, ultimately, it secures the investments done in
software development.
It may well be the case that ISO Prolog is not the best possible
standard: no standard I know enjoys this property. Indeed, there are
several things that I do not like in ISO Prolog. But I believe that it
is a reasonable compromise. Moreover, I do believe that following ISO
Prolog is much, much better than following no standard at all.
These considerations seem to be part of the common knowledge of other
communities. I follow quite closely the C++ standardization process
and the development of g++ (the GNU C++ compiler). I must say that the
entire C++ community (users and providers) really strive for standard
conformance. As far as I can see, providers do not hesitate to break
backward compatibility (even though this is done in two or more
steps), and users are more than willing to catch up by modifying their
programs for the sake of standardization.
I apologize to those who, like myself, regard the above sentences as
overwhelmingly obvious. I really do hope that the discussion will
prove they were superfluous.
Conclusion
----------
In my opinion, the bottom line is:
1) Does the logic programming community want to have a standard?
2) If so, is ISO Prolog the "right" standard?
3) If ISO Prolog is _not_ the "right" standard, why?
---------------------------------------------------------------------
Fernando Pereira
<bag...@di.unipi.it> wrote:
> In my opinion, the bottom line is:
>
> 1) Does the logic programming community want to have a standard?
> 2) If so, is ISO Prolog the "right" standard?
> 3) If ISO Prolog is _not_ the "right" standard, why?
discussions on the value, status and prospects of the ISO in an archive of
this newsgroup from the relevant period, if that exists anywhere. To cut a
long story short:
1) *Some* members of the community may have wanted to have a standard, but
many influential ones at the time either did not think it was the highest
priority or thought that the process was wrong-headed.
2) I've been out of these debates for quite a while, but when I was paying
any attention, I did not think so, and neither did some of the main Prolog
suppliers at the time, or some well-known experts like Richard O'Keefe,
who posted many detailed critiques of the draft standard.
3) You'll have to go back to the actual discussions of the draft to
understand the specific objections. The main meta-objection is that the
standard, rather than codifying existing practice, tried to "straighten
out" Prolog by the lights of the standard committee. This is a recipe for
standard irrelevance, as anyone who has had contact with standards
processes knows. Another problem is that the ISO process is too burdensome
to participate in for all but the most committed or most well-endowed
individuals and organizations (many expensive meetings, many hours off
from one's real job). Prolog suppliers were small companies with very
limited resources and could not afford devoting their most capable experts
to developing a standard of dubious significance, when that was not what
most of their customers were clamoring for (they were clamoring for
cross-platform compatibility, GUIs, DB interfaces, better integration with
non-Prolog code and legacy applications, smaller footprint, better
training and support).
-- F
Paulo Moura
Roberto Bagnara wrote:
> ...
> For these reasons, I think I can give an answer to the question in the
> title of this writing: no, generally speaking, the ISO Prolog standard
> is _not_ taken seriously (there are exceptions, of course: for
> instance, the developers of B-Prolog appear to seek for standard
> conformance).
I'm writing software intended to run under any Prolog compiler and I
have to agree with you: is a nightmare. I spend more time dealing with
bad documentation, bugs and incompatibilities that I spend devolping my
programs. But the number of Prolog compilers that are moving towards the
ISO Prolog conformance is increasing: IF/Prolog, Prolog II+ 4.5,
Calypso, YAP, SWI, B-Prolog, ALS and possibly others. It's up to us,
users, to express by our compiler choices that we want better support
for the ISO standard.
Regards,
Paulo
----------------------------------------------------
Paulo Jorge Lopes de Moura
Dep. of Mathematics phone: +351 39 791156
University of Coimbra fax: +351 39 832568
3000 Coimbra
Portugal
mailto:pmo...@mat.uc.pt
http://www.ci.uc.pt/logtalk/pmoura.html
----------------------------------------------------
Mats Carlsson
Quintus and SICStus Prologs. The discussion is limited to Part 1 of
the standard (general core).
It's true that these Prologs are not standard conforming today, the
main reason being that they were released before the standard was
finalized. I was active for many years in the standards committee,
and although I was not very enthusiastic about the work in its early
phases, it did converge a lot towards an acceptable compromise in the
end. Indeed, the committee finally decided to standardize most of
"Edinburgh Prolog" including many of the modern features invented in
Quintus Prolog in particular (stream I/O, the error system, semantics
of database updates, etc.).
Here's a bit of terminology from the standard:
A conforming Prolog processor shall be accompanied by documentation
that completes the definition of every _implementation defined_ and
_implementation specific_ feature specified in this part of ISO/IEC
13211.
A processor may support, as an _implementation specific_ feature, any
construct that is implicitly or explicitly undefined in this part of
ISO/IEC 13211.
A _conforming_ Prolog goal is one whose execution is defined by the
constructs specified in this part of ISO/IEC 13211, and the
_implementation defined_ and _implementation specific_ features
supported by the processor.
A _strictly conforming_ Prolog goal is one whose execution is defined
by the constructs specified in this part of ISO/IEC 13211, and the
_implementation defined_ features supported by the processor.
In particular, syntax extensions are allowed as an implementation
specific feature, as long as they do not change the meaning of
conforming Prolog text.
Roberto Bagnara raised some points about syntax in SICStus Prolog.
The first point concerned using ! as an postfix operator. As
explained above, it would be a valid extension (an implementation
specific feature) to allow operators as operands without
parenthesization. Also, the particular case only exists for obscure
purposes in the CLPFD solver. It would be a small sacrifice to
replace ! by something else there. Another point concerned some
details of token syntax.
These syntactic deviations are fairly small, and could easily
be handled by a conversion tool that translates legacy Prolog text
into standard conforming syntax.
I would like to mention another issue which cannot be easily handled by
a conversion tool: the semantics of calls to dynamic predicates in the
presence of asserts and retracts. Clause 7.5.4 of the standard reads:
Any change in the database that occurs as the result of executing a
goal (for example, when the activator of a subgoal is a call of
assertz/1 or retract/1) shall affect only an activation whose
execution begins afterwards. The change shall not affect any
activation that is currently being executed.
Try e.g. in your favorite Prolog system:
| ?- assert(foo(1)),
assert(foo(2)),
assert(foo(3)),
foo(X),
retractall(foo(3)),
assert(foo(4)).
The standard conforming answer given by Quintus and SICStus Prologs is:
X = 1 ;
X = 2 ;
X = 3 ;
no
There's nothing undefined about the semantics of dynamic calls, so
it's difficult to imagine any valid implementation specific feature
that would yield a different answer.
The issues of bytes, characters and I/O are major areas of
non-conformance. In a wise effort to support wide character sets, the
standard has taken pains to enforce the distinction between a _byte_
(8 bits), a _character code_ (implementation defined, but hardly more
than 32 bits), and a _character_ (an atom of length 1). Prolog text
and atoms are composed of characters, not bytes. Files can be opened
in either binary mode, dealing with bytes, or text mode, dealing with
characters. Many of the byte I/O built-ins inherited from Dec-10
Prolog (get0/1, put/1, skip/1 etc.) have had to go, replaced by one
set of built-ins for binary streams and another for text streams.
atom_chars/2 and number_chars/2 deal with characters, whereas
atom_codes/2 and number_codes/2 deal with character codes. And so on.
As a first step in this direction, Peter Szeredi, currently visiting
SICS, has produced a prototype "SICStus with wide characters"
supporting any wide character set e.g. Unicode or EUC
via appropriate hook functions and environment variables. A
description of the prototype as available at:
ftp://ftp.sics.se/archive/sicstus3/wcx_doc.txt
Lately, we have had many users asking us to move faster towards
standard conformance. We are just embarking on merging Quintus and
SICStus Prologs, so now is the right moment to make a decision about
standard conformance. Even with compatibility packages, it's not
realistic to expect both standard conformance and 100% backward
compatibility of legacy code. However, Quintus and SICStus Prologs
are really not that far from the standard, so any porting effort would
seem to be manageable and worthwhile in the long run. You can
definitely count us among the vendors moving towards standard
conformance.
Mats Carlsson, Prolog team leader
Paul Holmes-Higgin
wrote:
> ...
>Lately, we have had many users asking us to move faster towards
>standard conformance. We are just embarking on merging Quintus and
>SICStus Prologs, so now is the right moment to make a decision about
>standard conformance. Even with compatibility packages, it's not
>realistic to expect both standard conformance and 100% backward
>compatibility of legacy code. However, Quintus and SICStus Prologs
>are really not that far from the standard, so any porting effort would
>seem to be manageable and worthwhile in the long run. You can
>definitely count us among the vendors moving towards standard
>conformance.
>
>Mats Carlsson, Prolog team leader
It looks like we are very close to completing Part 2 of the Standard,
which addresses modules. It is also now time to think about any
modifications or updates to Part 1 of the standard. There's a good
chance that there will be a session that coincides with the Practical
Applications of Prolog conference in a few months, where people will
have the opportunity to make suggestions for changes. With a number
of new Prolog implementations around, and Quintus/SICStus
consolidation, it would seem an ideal time to reconsider the standard.
As soon as any details about this session become available, I'll make
sure the announcement reaches here.
Best regards
Paul
---
Paul Holmes-Higgin
Director of Tehnology
Resumix Limited