|
Is the ISO Prolog standard taken seriously?
Roberto Bagnara
In ShortDuring 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:
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. PrologueThe 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 TroublesThe 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:
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). Syntax: SICStus Prolog versus ISO PrologThe 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] ? yeswhile with an ISO-conformant system you would get | ?- name('abc\x20\def', X). X = [97,98,99,32,100,101,102] ? yesThe 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 accountNo 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. ConclusionIn my opinion, the bottom line is:
[Page last updated on December 10, 1999, 11:30:49.] |
||||||||
bagnara@cs.unipr.it |
Home | Personal | Papers | Teaching | Interests | People | Links | About |