CINXE.COM

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <HTML> <HEAD> <meta http-equiv=Content-Type content="text/html; charset=ISO-8859-1"> <TITLE>SWI7 and ISO Prolog</TITLE><LINK REL=home HREF="index.html"> <link rel=made href="mailto:ulrich%40complang.tuwien.ac.at" title="Ulrich Neumerkel"> <STYLE type="text/css"> body { background-color: white; max-width: 90ex; } p { } .note { font-size: 0.85em } .min { font-size: 0.5em } tr { } pre { margin-left: 1.5em; margin-right: 1.5em; border: 1px dotted; padding-top: 5px; padding-left: 5px; padding-bottom: 5px; background-color: #f8f8f8; max-width: 57em; } code { } pre.codex { margin-left: 1.5em; margin-right: 1.5em; border: 1px dotted; padding-top: 5px; padding-left: 5px; padding-bottom: 5px; } u { background: #ffd8d8 } /* .codx { background: #f0f2f9 } */ .codx { background: #e0e0ff } .bad { background: #ffe4e4 } .badm { background: #ff4040 } /* misinterpretation */ .badr { background: #ff8080 } /* rejection */ .bads { background: #ffd0d0 } /* syntactic variation */ .badx { background: #ffeaea } /* extension */ .good { background: #e4ffe4 } .unkn { } /* unknown */ .tabelle { border-collapse: collapse;} .tabelle td {border: 1px solid silver} .tabelle th {border: 1px solid silver} </STYLE> </HEAD> <BODY> <H1>SWI7 and ISO Prolog</H1> <DL> <DT><DD><a href="mailto:ulrich%40complang.tuwien.ac.at?subject=SWI7_and_ISO">Ulrich Neumerkel</a>, editor of ISO/IEC 13211-1 (core). <DL> <DT>2013-12-04 First announcement (<a href="https://lists.iai.uni-bonn.de/pipermail/swi-prolog/2013/011859.html">list</a>,<a href=2013-12-04-SWI-Prolog_7>copy</a>) <DT>2013-12-08 <a href="#adding_conforming_dot">Adding dot-notation in an ISO conforming manner</a> (<a href="https://lists.iai.uni-bonn.de/pipermail/swi-prolog/2013/011938.html">list</a>,<a href=2013-12-08-SWIPL-Adding_dot-notation>copy</a>) <DT>2014-09-23 <a href="#strings">Add remark on non-conformance of SWI7's strings</a> <DT>2015-09-10 <a href="#strings_less_non_conforming">How to make SWI7 strings a bit less non-conforming</a> </DL></DL> <p>Recently, SWI 7 has been released as a successor to SWI-Prolog 6. After discussions, a document titled <a href="swi/Directions">SWI-Prolog future directions</a> henceforth called "Future Directions" has been issued. The document refers to "the ISO standard" right from the first sentence on and requires a detailed reply, since the ISO standard, its standardization process, as well as SWI7's relation to it is presented in a misleading and inaccurate manner. <h3>What is ISO Prolog?</h3>ISO Prolog is the language described in <span class=codx>ISO/IEC 13211-1:1995 (core) including Cor.1:2007, Cor.2:2012</span> and <span class=codx>ISO/IEC 13211-2:2000</span>. I will refer to IS 13211-1 (core) only, since I am its editor. <span class=codx>References to the codex</span> are highlighted. <p>ISO Prolog resulted out of a process which begins in 1984; formally started in 1987 after 21 nations approved the "New Work Item programming language Prolog". More than 120 individuals contributed to this project with Roger Scowen as convener and editor. It was published as an International Standard in 1995. It is maintained by a working group (ISO/IEC JTC1 SC22 WG17) with two published technical corrigenda so far. <p>ISO Prolog is a voluntary standard, like most International Standards, meaning that it serves as a precise reference that everyone can adopt or not. Vendors and providers conforming to ISO Prolog will announce this via self-declaration, often in the very first sentence to ease procurement formalities; contracts refer to it similarly. <p>A system like SWI7 is free to decide whatever it wants with respect to ISO Prolog. However, the statements in "Future Directions" misrepresent the current state with respect to ISO. <h2>SWI7 did give up its rudimentary ISO compliance</h2>SWI7 changes the meaning of existing language syntax and semantics compared to SWI-Prolog 6. Neither SWI7 nor SWI-Prolog 6 are <a href=conformity_assessment>ISO compliant</a>. But SWI7 changes key properties in the language. These changes are not an extension to ISO Prolog. There are ways to extend ISO Prolog such that existing conforming programs and data are not affected. See <span class=codx>5.5 Extensions</span>. But the changes in SWI7 are a clear departure from ISO. <p>"Future directions" concedes that SWI-Prolog never followed ISO errors very closely which is accurate. However, this is in no way as important as the other changes to SWI7. Namely, the change of canonical syntax which makes term syntax incompatible to other systems and also previous versions of SWI-Prolog. <h3>SWI7 breaks canonical syntax</h3> Low overhead canonical syntax is one of the key properties of ISO Prolog syntax. In this manner terms can be "serialized", stored or transmitted to other Prolog systems independently of the operator declarations. <p>However, SWI7 can no longer read ISO conforming canonical syntax. This means that terms written by an ISO Prolog system can no longer be read by SWI7. Not even terms written by SWI-Prolog 6 can be read by SWI7. This means that logfiles or other data that have been generated with <code>write_canonical/1</code> in the past and in the hope to be readable in the future, cannot be read reliably in SWI7. An example of a term in canonical syntax that can no longer be read by SWI7: <pre> ?- writeq('.'(a,[])). <span class=bad>ERROR: Type error: `dict' expected, found `a'</span> </pre> <span class=codx>Expected: <code>[a]</code></span>. <p> Also, SWI7 no longer writes canonical syntax but a proper version of it which may again be a source of instability when a reader in another language is written to read canonical syntax only. So while the written Prolog text is (at least sometimes) valid Prolog text, it is not conforming canonical syntax. <p> To repeat, canonical syntax was meant as a stable, reliable data format. This is no longer the case in SWI7. Adding options for "traditional" behavior does not improve ISO conformance. <p><a name=adding_conforming_dot></a> <b>Adding a conforming infix dot</b>. The actual motivation for the changes in SWI7 seems to be the desire to distinguish lists and the (.)-notation. This could be achieved in an ISO conforming manner by adding the following extension instead: In case there is no current op-declaration for an operator . and the dot does not serve as operand: interpret dot as an infix operator that maps to '$dot'/2 or anything else. In this manner the canonical syntax remains unaffected. <p> With such an extension the following would hold: <pre> ?- '.'(E,L) = [1,2]. E = 1, L = [2]. ?- .(E,L) = [1,2]. E = 1, L = [2]. ?- op(400,xfy,.). % That is: turn off special meaning of . true. ?- A.B = [1,2]. A = 1, B = [2]. </pre> <h3>General term analysis no longer works with functor/3</h3> <p>It is a basic assumption for code traversing terms that nonvar terms can be analyzed with <code>functor/3</code> or <code>(=..)/2</code>. This is no longer the case in SWI7. The SWI7-specific term <code>f()</code> cannot be analyzed. <pre> ?- catch(functor(f(),F,A),error(E,_),true). <span class=bad>E = domain_error(compound_non_zero_arity, f()).</span> ?- catch(functor(f,F,A),error(E,_),true). F = f, A = 0. </pre> <p>The domain error produced is quite misleading too, it claims that <code>functor/3</code> expects a "compound_non_zero_arity". But also atoms are admitted that are not of this domain. <p>Some other differences are documented in SWI7. <hr> <p>"Future directions" also criticizes ISO Prolog directly. Here are answers to some of them. <h3>Error handling</h3><p>It is accurate that error handling in ISO Prolog built-in predicates is more complex than in, say, Javascript. The reason is the very different, relational, nature of Prolog. <ul> <li>At runtime, logic variables may occur in data, which is unheard of in more traditional languages. Other languages have only values (some references) at runtime. And logic variables may even be shared to each other - without having a concrete value associated. The closest approximation to Prolog variables are uninitialized or "tainted" values that produce an error should their value be accessed inappropriately. Some of these accesses make sense in Prolog, some others do not. It is therefore necessary to define such errors explicitly. <li>With relations, there are no explicit return values. Instead, a regular argument is used. This implies that further errors are needed when a term does not correspond to the expected "return" type. While these errors look like a lot of overhead, they most of the time incur a single comparison for being a variable. </ul> To cope with these complexities, many error messages are derived from a compact "Template and mode" description. One of the biggest advantages of ISO's consistent error handling is that a programmer can understand most of it by looking at that definition, and understand everything by looking at the errors subclause. Also, for program analysis, the situation is clear. As an example, consider <a href="dtc2#8.4.4.2">keysort/2</a>. There are six error clauses <span class=codx>8.4.4.3 a up to f</span>. A functional or imperative language would only need two: b and e. <p> In SWI, some errors appear, some not, and sometimes unspecified errors appear. The programmer is forced to do experiments and hope that the next version of SWI does not change the assumptions made. Also, proving program properties becomes a very difficult venture. Ultimately, for ensuring diligence, a programmer has to write a proper validation suite. Or look at <a href=number_chars>collections of examples</a> to "understand" a specific predicate. Should we really make such tables for each and every predicate? <h3>Errors of call/1</h3><p>It is correctly observed, that in ISO, <code>call((fail,1))</code> must produce a type error. However, the reader is not informed why such seemingly erratic behaviour is required. The reason is the precise handling of Prolog's control structures, like cut, disjunction, if-then, if-then-else and the meta-call. Prior to ISO, there was no agreed upon way how to handle these control structures in the general case which led to all kinds of inconsistencies and bugs. ISO has given these constructs a precise meaning. There is no ambiguity whatsoever how control constructs are interpreted in ISO. Implementations that do not follow the standard by the letter do expose different behavior. And SWI does not comply fully - contrary to the claim made in "Future directions". As an example reported years ago, <code>call((fail,\+1))</code> shall fail, but produces an error in SWI. Further, the meaning of control constructs depends also on the libraries that have been loaded before <span class=codx>term-to-body conversion (7.6.2)</span>. Here is a minimal example in SWI. While nobody writes such code directly, similar constructs may be produced during goal or term expansions. <pre> ?- call((X=!,once((X,fail;true)))). false. ?- use_module(library(apply_macros)). % messages omitted true. ?- call((X=!,once((X,fail;true)))). <span class=bad>X = !</span>. </pre> <h3>Errors of length/2</h3>For length/2, the list argument might either be checked or unchecked. Both possibilities have their advantages and the differences are minor. However, there is a big difference if all Prolog systems behave the same way, or differ according to the current taste of an implementer. WG17 did deliberate both cases, did consider the history of the predicate, and various use cases and finally <b>made a decision</b>. Now, we have <a href=length>at least 5 systems that conform</a>, and some (including SWI) that do it differently. It is exactly this kind of superfluous diversity that prevents synergy between systems. <p> In general, SWI rather omits errors. The goal <pre> sort([],[t|1]) /* <span class=codx> 8.4.3.3 c </span> */ ; keysort([], [_|1]) /* <span class=codx> 8.4.4.3 c </span> */ ; a =.. [t|1] /* <span class=codx> 8.5.3.3 b </span> */ ; term_variables(_,[t|1]) /* <span class=codx> 8.5.5.3 a </span> */ ; findall(t,true,[t|1]) /* <span class=codx> 8.10.1.3 c </span> */ ; bagof(t,true,[t|1]) /* <span class=codx> 8.10.2.3 c </span> */ ; setof(t,true,[t|1]) /* <span class=codx> 8.10.3.3 c </span> */ ; atom_chars(a, [_|1]) /* <span class=codx> 8.16.4.3 c </span> */ ; number_chars(2,[_|1]) /* <span class=codx> 8.16.7.3 c </span> */ ; false. </pre> fails in SWI. But each single goal should produce a type error. <h3><a name=strings></a>Representing text</h3>A separate string type is one option to address issues of improved text representation. It is even explicitly mentioned in the standard as a possible extension. Yet "Future Directions" presents this as a "revival of the BSI Prolog standard" which cannot be, for BSI produced drafts only, never a standard. Nevertheless, SWI7's string extension does not conform since SWI7's strings do not possess a canonical write syntax. <p>Another ISO conforming option is to merge transparently the (internal) representation of chars and strings. Yet another option (maybe the simplest one) is to merge strings and atoms. All three approaches do not need to break with ISO Prolog. SWI7 chose a path of incompatibility and even foresees a further change by introducing a separate data type for characters — in addition to ISO's character type as atoms of length 1. <p><a name=strings_less_non_conforming></a> <b>How to make SWI7 strings a bit less non-conforming</b>. The best one can do within SWI7 is to <code>set_prolog_flag(double_quotes, chars)</code> and <code>set_prolog_flag(back_quotes, string)</code>. In this manner SWI7's <code>write_canonical/1</code> writes strings with backquotes as a conforming extension would do. <pre> ?- atom_string(abc,S), write_canonical(S). <span class=bad>"abc"</span> <span class=bad>S = "abc".</span> ?- set_prolog_flag(double_quotes, chars). true. ?- set_prolog_flag(back_quotes, string). true. ?- atom_string(abc,S), write_canonical(S). <span class=codx>`abc`</span> <span class=bad>S = "abc".</span> </pre> Not all cases are covered, though. Says <a href="http://www.cs.otago.ac.nz/staffpriv/ok/pllib.htm#strs">Richard O'Keefe</a>: <blockquote> What are we to do about Prolog systems where strings are written using double quotes? Wince, regret the JavaScript envy, and request a mode that is more Prolog-like.</blockquote> <h3>Syntax</h3>The document calls ISO syntax for octal and hexadecimal escape sequences like <code>'\141\'</code> and <code>'\x61\'</code> (both representing in ASCII the atom <code>a</code>) idiosyncratic. However, <s>9</s> 10 out of 10 systems recognize this notation correctly. See <a href="http://www.complang.tuwien.ac.at/ulrich/iso-prolog/conformity_assessment#108">#108</a>. If there is anything idiosyncratic in this context, it is the frequently changing extensions to escape sequences in SWI. <h3>SWI7 and education</h3>One very frequently mentioned requirement for realizing Prolog courses is a uniform set of predefined predicates. This would make the life of teachers much simpler. No need to change the material when going from one implementation to another. No hassles when a student has a more recent version installed. The <a href=prologue>Prolog prologue</a> was started with this in mind too. However, SWI seems to prefer to differ. Also, the statement about solving "the N-queens problems elegantly and in splendid isolation" is irritating. This is an insightful example to experience different labeling strategies in beginners' courses. And it helped other Prolog systems to identify and remove bugs in their systems thereby improving both the academic <b>and</b> industrial experience. A robust and reliable implementation should have no problems with such examples in any case. This is really the first time I see such derogatory remarks by an implementer. <h3>Is the ISO process really slow?</h3>In passing, "Future Directions" remarks that the process to enlarge the (ISO) Prolog language is "too slow". This now turns things upside down! Since 1995, 13211-1 is present. Yet, 18 years later, SWI has not fully adopted it. And for many years, SWI ignored ISO completely. Only recently a visible move was taken (2007-2010). SWI's syntax is still far away from complete conformity. Also, in other areas, SWI needed literally years to adapt to marginal changes. And sometimes refuses them altogether. <p>The ISO process is a very flexible and fast process. But to run at maximal speed it requires commitment, cooperation, and conformance. <h2>Conclusion</h2>SWI7 is a radical departure from ISO Prolog and its ancestor Edinburgh Prolog. SWI7 is still "a Prolog", there is no doubt — but a very different one. In other programming languages such radical changes have been reflected by changing the name of the language. <hr> <a href=".">ISO Prolog works</a>, <a href="http://validator.w3.org/check?uri=referer">Validated HTML</a> </body></html>