Information technology - Programming languages - Prolog - Part 1: General Core

Transcription

1 Information technology - Programming languages - Prolog - Part 1: General Core DRAFT TECHNICAL CORRIGENDUM 1 Draft technical corrigendum 1 to International Standard :1995 (E) was prepared Joint Technical Committee ISO/IEC JTC 1, Information technology NOTE - Some text in Mathematical font is expressed using Latex convention, i.e. surrounded with $ signs mapping mapping is used with a second meaning in the standard: add a second definition A function from a value of one type $T$ to a value of another type $R$ denoted $T \rightarrow R$ most general unifier (MGU) instance example because instance is not being used with the meaning defined in partial list A variable A variable. second argument second argument read-term end token. end token Axiom : Axiom: if x > 0 then x is the positive square root of x else undefined. Axiom: if x 0 then x is the non-negative square root of x else undefined Term -- double quoted list notation If a double quoted list represents an atom (i.e. the Prolog flag double_quotes has value atom ), the priority of the term should depend on whether or not the atom is an operator as in ISO/IEC states that the priority of an atom represented a double quoted list is always zero. the syntax rule the four syntax rules: term = double quoted list ; Abstract: l dql Priority: 0 Condition: Prolog flag double_quotes has value chars term = double quoted list ; Abstract: l dql Priority: 0 Condition: Prolog flag double_quotes has value code atom = double quoted list ; Abstract: a dql Priority: n Condition: Prolog flag double_quotes has value atom Condition: a is an operator atom = double quoted list ; Abstract: a dql Priority: 0 Condition: Prolog flag double_quotes has value atom Condition: a is not an operator c) 2) 2) if XN is the... 2) XN is the the first sentence: Tables 27 and 28 show the execution stack before and after executing the control construct ','(First, second). Tables 27 and 28 show the execution stack before and after executing the control construct ','(First, Second). Table 35 line 2 (else(w), CP) 1

2 (Else, CP) last example ';'('->'(!,fail), true), true). ';'(('->'(!,fail), true), true) Add additional errors: i) The value of an argument Culprit is not a member of the set $I$ - type_error(integer, Culprit) j) The value of an argument Culprit is not a member of the set $F$ - type_error(float, Culprit) example no. 35 shows these errors are required i) Twice replace imp_dep_atom Imp_dep_atom d) Chooses the first element of the list L Chooses the first element of the list L, unifies it with the term clause(head,body) Similarly for f) abolish/1: Description In the note, replace procedures identified procedure identified example no. 20 [a, b, f(b), f(a)] [a, b, f(a), f(b)] put_te/1 put_te(84). If the current output stream contains [..., 113,119,101,114,116] put_te(st_o, 84). If the stream associated with st_o contains [..., 113,119,101,114,116] put_te(84). If the current output stream contains [..., 113,119,101,114,84] put_te(st_o, 116). If the stream associated with st_o contains [..., 113,119,101,114,116] examples no. 2 and 3 st_o st_i example no. 6 (last) The current input stream is left with position pastend-of-stream. The current input stream is left in an undefined state. (Cf NOTE 2) d) Chooses a member of $Set_Op$ and the goal succeeds Chooses a member of $Set_Op$, unifies it with (Priority, Op_specifier, Operator), and the goal succeeds atom_chars/2 The sixth example in is atom_chars('north', ['N X]). Succeeds, unifying X with ['o', r', t', h']. but the procedural description does not permit this (c) : c) Else if Atom is an atom whose name is the sequence of characters $Seq$ and List unifies with a list L such that every element of L is the one-char atom whose name is the corresponding element of $Seq$, then the goal succeeds, atom_codes/2 The error noted in implies a similar change in this procedure (c) : c) Else if Atom is an atom whose name is the sequence of characters $Seq$ and List unifies with a list L such that every element of L is the character code of the corresponding element of $Seq$, then the goal succeeds, 2

3 Add a note pointing to the definition of F* ( ) example no. 21 '/'(7, 35) '//'(7, 35) example no. 23 '/'(140, 3+11) '//'(140, 3+11) example no example no. 48 float(5/3) float(5//3) example no example no example no. 5, example no example no. 6, example no. 6 type(integer,foo) type_error(evaluable,foo/0)!"#$%& '$%()*+(, - %. / #8%-'6$.2099:%;,< 3

4 The following points indicate possible problems with the standard, but do not specify corrections or cures Quoted characters The text does not define what character is denoted a double quote char or back quote char which is a single quoted character. Similar omissions exist for double quoted character and back quoted character. 6.5 It shall be implementation defined for each extended character whether it is a graphic char, or an alphanumeric char, or a solo char, This classification is incomplete in the following sense: - It is not enough to classify an extended character as an <<alphanumeric char>>, one has to also tell if it is a <<small letter char>>, <<capital letter char>> (e.g. NOTE 2 of 6.5 speaks of <<extended small letter char>>). - The notion of <<solo char>> is unfortunate: it contains characters that form a <<name token>> alone (! and ;), and punctuation characters, which cannot be part of an unquoted <<name token>>. Classifying an extended character as a <<solo char>> does not make this character usable as a token alone, because there is no syntactic rule for this (! and ; are included explicitly in <<name token>>). Along the lines of the Quintus/SICStus Prolog syntax, perhaps the category of <<solo char>> should be changed to mean only <<cut char>> and <<semicolon char>>, and a new category <<punctuation char>> is introduced to contain all other characters presently classified as solo. And there should be a non-terminal <<solo token>>, replacing <<semicolon token>> and <<cut token>> in <<name token>>, which is defined as: solo token = solo char ; The standard should let the user classify an extended character placing it in exactly one of the following character categories: graphic char small letter char capital letter char solo char layout char In addition to these, the notion of <<char>> covers the categories <<decimal digit char>>, <<underline char>>, <<punctuation char>> and <<meta char>> - It may not Annex A (informative) Issues still to be resolved make sense to allow the user to classify extended characters into one of these categories. Perhaps it may be useful to have a category <<other char>>, initially empty; any extended character classified as such would only be allowed in (double, back) quoted tokens. A wide character extension to SICStus Prolog allows the user to plug in arbitrary character sets and define, through C hook functions, the character-type mapping. This is a function taking a character code, and returning a constant denoting one of the above character categories. This extension is part of the SICStus Prolog 3.8 release. I hope the term <<implementation defined>> in the Prolog standard does allow such delegation of definitions to the user through hook functions. 6.5 and The distinction between PCS (Processor character set) and C (the set of characters) is quite confusing at first reading. It does make sense, for example, in SICStus Prolog there is a member of PCS with character_code 0, which is not a character (not a member of C) - as there cannot be a one-char atom representing a character with code 0. Giving an example of this kind would help the uninitiated reader. Also replacing the name <<character>> a qualified form, e.g. <<Prolog character>> would help. This is because currently the <<processor character set>> has members which are <<character>>s, and other members which are not - how would you call the letter things"? For example in the previous paragraph, referring to the character with code 0 was quite cumbersome, because formally the thing with code 0 is not a character , and The use of the built-in predicates <'/2 and =='/2 in defining the term order is not very elegant. Perhaps using the mathematical relation <, and the notion of <<identical terms>> would be preferable A reference to the definition of <<predicate indicator sequence>> and <<predicate indicator list>> in would be quite helpful here. Also perhaps these notions should be included in chapter 3. 4

5 7.6 Perhaps it would make sense to explicitly mention that an implementation may add other conversion steps, as an extension. The goal_expansion mechanism of SICStus Prolog is an example of such extensions a) Where is the definition and purpose of the <<callable term representing the built-in predicate BP>>. Also the <<MGU>> produced here is never used. Table 17 Why is the cut-parent of true shown to be equal to N-2? c) It might benefit the user if the Culprit in the error term here could be more precise than the whole argument of call/1. Maybe call((...,1)) raising type_error(callable, 1) should be allowed the standard example no. 6 This example should not output 3. Table 25, Table 26 The cut-parent of the first subgoal of the execution state with index CP is shown as CP - this should be different o) The introduction of a local cut in front of the Else part is artificial c) This says that a throw without an applicable catch causes a system error. This error condition is different from other errors, because in this situation it does not make sense to apply the rules concerning the effect of an error: says that the current goal should be replaced the goal throw(error(system_error,imp_def)). Perhaps it should be left implementation defined what should happen with uncaught exceptions e) It does not seem right to replace CP the cut-parent of each execution state g) The text R is used without definition NOTE The current operators do not affect output when there is a write option numbervars(true). This seems to be garbled Writing a term No method is provided for writing a curly bracketed term (6.3.6) with curly brackets d) Some implementations, e.g. SICStus, write <<.>> as <<'.'>> when quoted(true) is in force, to avoid confusion with end token. It might be good if the standard allowed this NOTE 4 (b) See the remark to c) A list of the error conditions and associated error terms for the built-in predicate Is the order of this list relevant? It should not be. If two or more error conditions apply, any of them could be raised a standard-conforming processor. Perhaps this issue is worth clarifying Consider The error conditions and examples for a bootstrapped built-in predicate are included in the appropriate clauses of the general built-in predicate. This is quite cumbersome, especially that error conditions use the argument names which appear only later, and only as part of the Prolog definitions. I would suggest to list the heads of the bootstrapped predicates earlier, so that the argument naming becomes more visible. An example of this: j) mentions the name <<Code>> which only appears buried in Prolog code on the next page in c) Maybe replace 2) and 3) with 2) (H:-B) unifies with (Head:-Body) examples no. 5, 10 and 12 Mention that the order of solutions is undefined. 5

6 examples no. 22, 23 and 24 (last three) Replacing <<Xs>> <<Ys>> might make these examples easier to understand get_code/1 should be defined in terms of get_code/2, just as it is done for get_char: get_code(code) :- current_input(s), get_code(s, Code) d) and j) Error condition j) makes little sense, given error condition d) example no. 4 The example is not fortunate, as the error permission_error(output, text_stream, user_output) would be also a valid outcome (see also the remark to 8.1.3) examples no These should raise the type_error(evaluable, foo/0) error, according to c) examples no. 25 and 26 '/'(7, -3) '//'(7, -3) And replace '/'(-7, 3) '//'(-7, 3) Perhaps it is worth adding extending the text Evaluates to an implementation dependent value which is either -2 or I suggest to add an error condition, so that current_op(_, 0, _) raises the error type_error(atom, 0) Maybe an error condition has to be added so that if atom_codes is called, e.g. as atom_codes(x, [foo]), it should raise a type_error(integer, foo) The error conditions of atom_codes and number_codes seem not to be in sync, and similarly for..._chars. Example:?- catch(atom_codes(f, [foo]), error(e,_), true). no.?- catch(number_codes(1, [foo]), error(e,_), true). E = type_error(integer,foo)? yes Explain the need for the last sentence before the NOTE: The approximate-addition function should satisfy last but one line round_r->z(x) = entier(x+1/2)>> Is it not the case that the IEEE FP standard allows other forms of rounding, e.g. rounding an integer+0.5 to the nearest *even* integer? If so, could this be allowed in standard Prolog? 6

7 Annex B (informative) Editorial notes Unusual characters Check the following characters are correctly printed Square root symbol: Greater than or equal symbol: Background These faults were noted after preparing for publication the text of ISO/IEC :1995 Prolog: Part 1 - General Core, and subsequent lists of errors noted Roger Scowen, Peter Szeredi, Pierre Deransart, and Ali Ed-Dbali. Roger Scowen (editor) 9 Birchwood Grove, Hampton, Middlesex United Kingdom TW12 3DU Telephone: +44 (0) roger.scowen@npl.co.uk October - November 2005 Document history 2006 April 15: Two further corrections are noted (3.125, 3.148). The structure is amended to be based on ISO/IEC :2004/Cor.1:2005 (E). Posted to Jonathan Hodgson for distribution and balloting within SC22. December 1: Posted to Jonathan Hodgson for distribution to, and discussion within JTC 1 SC 22 WG October 26: Copied from c:\rs0\prolog\da58.tex, and stored in c:\rs5\standard\st77.doc. Examples and sources are removed. 7