From owner-prolog-standard@LISTSERV.UGA.EDU Wed May 28 22:37:32 2014 Return-path: Envelope-to: ulrich@a4.complang.tuwien.ac.at Delivery-date: Wed, 28 May 2014 22:37:32 +0200 Received: from mips.complang.tuwien.ac.at ([128.130.173.64]) by a4.complang.tuwien.ac.at with esmtp (Exim 4.69) (envelope-from ) id 1WpkbM-0007mf-81 for ulrich@a4.complang.tuwien.ac.at; Wed, 28 May 2014 22:37:32 +0200 Received: from tuvok.kom.tuwien.ac.at ([192.35.241.66]) by mips.complang.tuwien.ac.at with esmtp (Exim 4.80) (envelope-from ) id 1WpkbM-0004TM-5a for ulrich@COMPLANG.TUWIEN.AC.AT; Wed, 28 May 2014 22:37:32 +0200 Received: from willow.cc.uga.edu (willow.cc.uga.edu [128.192.11.106]) by tuvok.kom.tuwien.ac.at (8.14.5/8.14.5) with ESMTP id s4SKbLHr023936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 May 2014 22:37:23 +0200 X-Connecting-Host: willow.cc.uga.edu [128.192.11.106] X-Connecting-Addr: 128.192.11.106 X-Sent-To: X-Sent-From: owner-prolog-standard@LISTSERV.UGA.EDU Received: from listserv.cc.uga.edu (listserv.uga.edu [128.192.1.75]) by willow.cc.uga.edu (8.13.8/8.13.8) with ESMTP id s4SHIgBV018076; Wed, 28 May 2014 16:33:07 -0400 Received: from LISTSERV.UGA.EDU by LISTSERV.UGA.EDU (LISTSERV-TCP/IP release 1.8d) with spool id 10720038 for PROLOG-STANDARD@LISTSERV.UGA.EDU; Wed, 28 May 2014 16:33:07 -0400 Received: from fsmsg2.sics.se (fsmsg2.sics.se [193.10.64.244]) by listserv.uga.edu (8.13.8/8.13.8) with ESMTP id s4SKWus4031421 for ; Wed, 28 May 2014 16:33:01 -0400 Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id s4SKV3HJ010212 for ; Wed, 28 May 2014 22:32:55 +0200 Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1m49pcx3tj-1 for ; Wed, 28 May 2014 22:32:54 +0200 Received: from [192.168.0.20] (81-231-83-157-no38.tbcn.telia.com [81.231.83.157]) (Authenticated sender: perm@sics.se) by letter.sics.se (Postfix) with ESMTPSA id AE17440116 for ; Wed, 28 May 2014 22:32:54 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) References: <535E6D93.60804@sju.edu> X-Mailer: Apple Mail (2.1878.2) X-Proofpoint-Spam-Reason: safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96,1.0.14,0.0.0000 definitions=2014-05-28_07:2014-05-28,2014-05-28,1970-01-01 signatures=0 X-Scanned-By: Digested by UGA Mail Gateway on 128.192.1.75 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by listserv.uga.edu id s4SKX7s4031571 Message-ID: Date: Wed, 28 May 2014 22:32:53 +0200 Reply-To: ISO Prolog Standard discussion Sender: ISO Prolog Standard discussion From: Per Mildner Subject: Re: [PROLOG-STANDARD] DCGs To: PROLOG-STANDARD@LISTSERV.UGA.EDU In-Reply-To: <535E6D93.60804@sju.edu> X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.2.7 (tuvok.kom.tuwien.ac.at [192.35.241.66]); Wed, 28 May 2014 22:37:24 +0200 (CEST) X-Spam-Status: LOW ; -106 X-Spam-Level: - X-Spam-TU-Processing-Host: tuvok.kom.tuwien.ac.at X-Virus-Scanned: by amavisd-new on vc9.kom.tuwien.ac.at Status: RO On 28 Apr 2014, at 17:02, Jonathan Hodgson wrote: > Dear Standardizer, > > Please submit your comment son the latest DCGs draft > http://people.sju.edu/~jhodgson/wg17/Vienna2014/Drafts/dcgsdin140408.pdf > > by June 1st. > > Jonathan Thanks to everyone who has worked with this. My comments on the DCG draft, dated April 8, 2014 (the "TR"). (Be advised that I am not a native english speaker, some of my comments on the language in the TR may be affected by that. Also, my language may sometimes be harsh but I realize what a huge effort that has been put into this TR by those involved.) General: Many aspects of grammar rules are closely related to similar aspects of clauses. It would therefore make sense to re-use the corresponding clause-related definitions and ways of expressiong things when describing things related to grammar-rules. For instance, the definition of "grammar-rule" ought to more closely follow the way "clause-term" is defined in Part 1. Similarly for definitions and descriptions related to control structures (most notably if-then-else). Similarly for the grammar concepts corresponding to predication, predicate indicator, predicate, procedure. if-then-else deserves a special mention. The unfortunate fact that a compound term with principal functor (;)/2 is used both for alternative/disjunction and if-then-else makes it somewhat tedious to define. Part 1 gets this right, e.g. in 7.8.8, and this TR would do well to follow the lead of Part 1. The current description, in this TR, of if-then-else is hopelessly confused. Also, this TR seem a lax in its use of non-terminal, functor, goal vs term, etc. Part 1 is very clear which is which. Various "helpful" statements in the normative text corrupts the formal nature of this TR and can easily introduce incorrect or misleading text in the normative part of this TR. Such helpful statements belong in non-normaltive notes, if they should appear at all. After all, as pointed out in clause 1 of Part 1, the standard "... is inteded for use by implementors and knowledgeable programmers, and is not a tutorial". As an example of such (un-) helpful statements, consider the incorrect claim (in 7.14.2) that empty grammar bodies must contain "[]" (empty terminal sequence) which could be interpreted as something an implementation must enforce. Similarly for "3.14 grammar-rule-body" that limits the definition to the case when it is the second argument of a rule, leaving the first argument of phrase/1 without a formal definition. This TR seems confused about whether grammar rules are translated to clauses or not, e.g. as part of preparing for execution. I think they should be, as is hinted in a non-normative note in 6.2.1.3, and that this should be used to resolve the question what happens when rules and clauses for the same predicate are mixed in the program text. If grammar rules are just an alternative syntax for clauses, and a procedure can be defined by a mixture of grammar rules and clauses, then it is obvious that "being a non-terminal" does not make sense as a property of procedures (and, therefore, the predicate property "expanded_from/1" makes no sense). I think much in this TR could be simplified if we finally puts to rest the idea that grammar rules are anything but an alternative syntax for clauses. A simple translation is, to my understanding, how it is implemented in most systems, and it removes the need for (and point of) the grammar specific existence error terms, predicate property, etc. I think normative text should spell out words and should avoid abbreviations like "wrt.", "resp.". The status of subclause 10 is unclear. Is it normative, if so, to what level of detail? 6.2.1.3 says that "Subclause 10 of this TR defines how a grammar rule in Prolog text is expanded into an equivalent clause when Prolog is text is prepared for execution.". Unfortunately this is in a non-normative NOTE, so it needs to be stated in normative text. Details: "1 Scope" "1 Scope ... c) A set of built-in ... expanding grammar rutes" This TR does not specify any built-ins for expanding grammar rules. "1 Scope ... d) A Reference ..." Should be "d) A reference ..." "1 Scope ... NOTE -- The limitationsm expressed in clause 1, Scope, of ..." What "limitations" is this referring to? (the last a--f items?) Does the scope (the first a--f items) of clause 1 not apply? "3 Definitions" "3.5 cover,a terminal-sequence..." Should be "... cover, a ..." "3.13 grammar-rule: a compound term ..." Why does this definition use a different formulaton than 3.33 in Part 1 (which specifies "clause-term"). That is, should 3.13 not define something like "grammar-rule-term" and relate it to "read-term" instead? "3.14 grammar-rule-body: The second argument of a grammar rule. ..." This is misleading, "grammar-rule-body" is used in many places, not just as second argument of a grammar rule. "3.17 non-terminal ..., i.e. ... that denotes a non terminal symbol of a grammar rule." There will be no grammar rule for "alternative" or "concatenation". Therefore (...;...) and (...,...) does not denote "a non terminal symbol of a grammar rule", therefore 3.17 does not define (;)//2 or (',')//2 as non-terminals. "3.19 parsing ... consuming terminal-sequences, assigning them to ... non-terminals ..." Since terminal-sequence (3.24) is "a list ... 3.99 ..." a terminal-sequence is a "proper" list, i.e. its last tail is the empty list. This means that, e.g. a call to phrase(foo,[a,b|Tail],Tail) does not perform "parsing" as defined here (since the argument is not "a list"). "3.22 steadfastness of a goal wrt. an argument. ..." "3.22 ... its argument list ..." Should be "... its sequence of arguments ..." or some such. In either case "list" should not be used since it has a specific meaning in the standard. A goal (3.81) is a predication (3.133) which has "... a _sequence_ of ... arguments". "3.22 ... a new variable ..." Presumably this means new variable with respect to the goal G, but "3.16 new variable" is defined for terms, it is not defined for goals. "3.22 ... the execution ... is the same" What does it mean for two executions to be "the same"? "3.25 terminal-sequence, comprehensive ..." "3.25 ... Terminal sequence containing a (possibly empty) prefix covered ... by a grammar-rule-body ..." This can be misread as "Terminal sequence ... covered ... by" but it is the prefix that is covered. "3.25 ... Terminal sequence containing a (possibly empty) prefix covered ... by a grammar-rule-body ..." The definition does not properly describe the case with an empty prefix, since the empty prefix is not necessary covered by any grammar-rule-body (in the program), e.g. if there are no grammar rules at all in the program. E.g. phrase([],_,_) succeeds even if there are no rules (or clauses) in the program. "3.25 ... i.e. accepted resp. generated by phrase/3 ..." This belongs in a non-normative note, and should say "e.g. accepted ...", rather than "i.e accepted ..." "3.24 terminal-sequence: A list ... 3.99 ..." This implies that terminal sequence and thus comprehensive terminal-sequence and remaining terminal sequence are always []-terminated. This i not how they are use in this TR. "3.25 terminal-sequence, comprehensive: Terminal sequence ..." This implies that the comprehensive terminal sequence is a [] -terminated list. Is this intentional? "3.26 terminal-sequence, remaining ..." This implies that the remaining terminal-sequence is a [] -terminated list. Is this intentional? "6.1.3 Variable names convention for terminal-sequences" "6.1.3 This TR uses ... S to represent the terminal-sequences ..." The S does not represent a []-terminated list, and therefore does not represent a terminal-sequence as defined in 3.25. Similarly for "Si+1" and "remaining terminal-sequence". "6.1.3 ... after processing Si with a grammar rule" What does "processing with a grammar rule" mean? "6.2 Prolog test and data" "6.2 ... (1) directives, (2) grammar rules, and (3) clauses of user-defined procedures ..." Given that rules and clauses are so similar (or even the same thing once prepared for execution), this should perhaps says "(2) grammar rules of user-defined procedures ..." "6.2.1.1 Directives ... with exception ..." Should be "... with the exception ..." "6.2.1.3 Grammar rules" "6.2.1.3 ... NOTE -- Subclause 10 of this TR defines how a grammar rule in Prolog text is expanded into an equivanet clause when Prolog text is prepared for execution." So, 6.2.1.3 non-normatively says that grammar rules are translated to an ordinary clause when the Prolog text is prepared for execution. This should be stated in normative text. "6.2.1.4 Semicontexts" "6.2.1.4 ... Abstract: rc ... Abstract: r ..." Why the names "rc" and "r"? "7.4.2 Directives" "7.4.2 ... If the Prolog processor supports Prolog Modules ..." Are there other implications when modules are supported, e.g. meta declarations of non-terminals? "7.13 Predicate properties" "7.13 ... expanded_from(A//N) ..." If grammar rules are just an alternative way of specifying the clauses of a procedure then the property of being expanded from a grammar rule is a propery of a clause, it is not a property of a procedure. Especially when a procedure is defined by a mixture of clauses and grammar rules (as it can be, I think). "7.13 ... expanded_from(A//N) ..." This seems to say that, if Part 2 is supported, then this predicate property must be supported. As argued above the property makes no sense, at least not in common implementations of grammar rules, so making this mandatory would be unfortunate. Perhaps the property could make sense in some implementation, in which case the property could be optional. "7.14 Grammar rules" "7.14.1 terminals and non-terminals" "7.14.1 ... One or more terminals are represented by terms directly contained in lists in order to distinguish them from non-terminals." There is something missing here, the context is clearly related to terminals appearing in grammar rule bodies but this is not mentioned. "7.14.2 Format of grammar rules" "7.14.2 ... grammar rules are constructed from non-terminals, terminals and control constructs." This is redundant as "non-terminals" includes the "control constructs". "7.14.2 ... The head(of a grammar rules) is a non-terminal or the conjunction of a non-terminal and, following, a terminal-sequence (a semicontext, see 7.14.3)" It is unfortunate to use "conjunction", with all its Prolog specific meanings, to mean co-location as is done here. Clearer to just say "The head (of a grammar rule) is a non-terminal, or a non-terminal and a terminal-sequence (a semicontext, see 7.14.3)" "7.14.2 ... An empty body is represented by an empty terminal sequence: GRHead --> []. This empty terminal sequence cannot be omitted ..." This belongs in a non-normative note, and, as it stands, it is completely incorrect. As it stands it seems to say that [] is the only allowed way to "represent and empty body" (whatever that means), e.g. that an implementation must not allow things like "foo --> { true }." It would be better to replace this with a suitably relaxed non-normative note. "7.14.3.1 Description" "7.14.3.1 ... A semicontext contains terminals that are prefixed to the remaining terminal-sequence after successful application of the grammar rule." The terminals of the semicontext makes up a prefix OF the remaining terminal sequence after successful application of the grammar rule. "7.14.3.2 Examples" "7.14.3.2 ... NOTES ... 3 There are cases, where the remaining terminal-sequence is the comprehensive terminal-sequence, e.g. with the following grammar rule, but there is a trailing sequence as the following example shows." This sentense is hard to parse (no pun intended). "7.14.3.2 ... NOTES ... 3 ... a trailing sequence ..." Proper terminology? "trailing sequence"? "7.14.3.2 ... which is expanded ... Other places says things like "may be expanded" so something like that should be used here as well. "7.14.3.2 ... expanded to ... nt(S0, [word|S]) :- S0 = S. ..." I think it is cleared if all examples of expansion use the same, naive, expansion method, i.e. the one specified in subclause 10. Applying various "peephole optimizations" just makes things less clear. So, the example expansion should be something like "nt(S0, S) :- S0 = S1, S = [word|S1]." (besides, if minimal examples are desirable, then "nt(S,[word|S])." should be used). "7.14.4 Non-terminal indicator" "7.14.4 ... The non-terminal indicator //(A,N) ... whose functor is A and whose arity is N." This is wrong. A, in //(A,N) is not a functor. A functor is "an identified together with an arity" (3.77). "7.15 Grammar control constructs" "7.15 ... special non-terminals ...: (->)//2 in an if-then-else ..." (->)//2 should not be in this list of non-terminals. (->)//2 is not a non-terminal (and it does not denote a non-terminal). if-then-else has three parts, and it is unfortunate that it shares its principal functor with alternative, but the first sub-term of an if-then-else is not a non-terminal. Part 1 gets it right when it describes if-then-else, disjunction, read-term vs term vs clause, term vd goal etc. This TR does not keep concepts apart properly. "7.15 ... The correspondence between the following sublauses and the corresponding formal definitions is given by the princal functor of the first argument of the clauses of predicate dcg_cbody/4 in subclause 10." This is not true, mostly because 7.15.2 and 7.15.5 are broken. "7.15 ... Expansion of grammar control constructs ... The Grammar control constructs ..." Inconsistent casing of "grammar". "7.15 ... The following subclauses explicate the linkages between the terminal sequences upon expansion of the control constructs." It should, but for many control constructs (e.g. call//1, phrase//1) it does not say anything about how the terminal sequences are linked. "7.15.1 []//0 -- empty terminal-sequence" "7.15.1 []//0 -- empty terminal-sequence ... empty terminal sequence ..." inconsistent hyphenation. "7.15.2 ('|')//2 -- list separator" Surely you mean ('.')//2. Also, the text is redundant in mentioning both left hand side and first argument; and right hand side and second argument. "7.15.4 (;)//2 -- alternative" As in Part 1, 7.8.6, subclause 7.15.4 ought to mention the if-then-else construct. "7.15.4 ... is subject to expansion -- GBFirst first, and then GBSecond." This should not specify the order of expansion. By specifying an order you imply that any side effects (e.g. errors), of the expansion process itself, must come in a particular order. I assume that such a strict ordering is not intended here. "7.15.4 ... is expanded to ... (;)/2 wrt. subclause 7.8.6 of ..." I do not understand this. In what sense is what thing "with respect to 7.8.6"? "7.15.4 ... the expansion of GBFirst and GBSecond shall be arguments of that disjunction, which results from expansion of (;)//2". It should say that the expansion of GBFirst should the first argument of the disjunction, and similarly for GBSecond. Also, should it say "... of THE disjunction, which ..."? "7.15.4 ... ?-write_canonical(...)" Missing spaces, should be "7.15.4 ... ? - write_canonical(...)" for consistency with 8.1.1.5. I find the entire NOTE superfluous. After all, as Part 1 puts it, this text should be "... inteded for use by implementors and knowledgeable programmers, and is not a tutorial". "7.15.5 ->//2 -- if-then-else" With the operator definitions of this TR ->//2 should be written as (->)//2. The title should say (;)//2 since this is the "principal nonterminal indicator" (my own invention). See 7.8.8 in Part 1 for how to describe the two different functions of ';'(A,B). "7.15.5 ... is a compound term with functor (->)//2." (->)//2 is not a functor. The _term_ has (principal) functor (->)/2. "7.15.5 ... when the first argument of (;)//2 is not a (->)//2." This is sloppy. See 7.8.8 for how to express this correctly. (the first argument of (;)//2? surely that would be (;). and what is "a (->)//2"? "7.15.5 ... The grammar control construct (;)//2 has as arguments a grammar body GBFirst and a second grammar body GBSecond" This is nonsensical. The grammar control construct defined by 7.15.5 is "if-then-else" so why does it mention the ambiguous "_the_ grammar control construct (;)//2" there are two different constrol constructs, "alternative" and "if-then-else" that are both specified using a compound term with principal functor (;)/2. As before, see 7.8.8 for how to get this right. "7.15.5 ... GBFirst and a second grammar body GBSecond" It would be clearer if the variable names in subclause 10 and in 7.* were the same. "7.15.5 ... The result of expansion is an if-then-else ..., resulting from expansion of (;)//2, with the if-then construct ->(GBIfExpanded, GBThenExpanded) as first, and GBSecondExpanded as second argument." No. There is nothing like an "if-then construct" here. 7.8.8 defines if-then-else construct with three parts If, Then, and Else and 7.15.5 should specify how they relate to the corresponding _three_ parts of a (grammar) if-then-else. "7.15.6 '|'//2 -- second form of alternative" With the operator definitions of this TR '|'//2 should be written as ('|')//2. "7.15.6 ... NOTE -- ... ('|')//2 shall not be used for "if-then-else" ... " Forbidding '|'((A->B),C) to be equivalent to ';'((A->B),C), i.e. to be used for if-then-else, would have unfortunate compatibility implications. This would break existing code that currently works in those Prolog implementation that translate infix use of '|' into infix ';'. I see no obvious benefit in disallowing the use of ('|')//2 as if-then-else, at least as a permitted extension. "7.15.7 {}//2 -- grammar-body-goal" "7.15.7 ... The non-terminal {G}, with G a Prolog goal, according to ISO/IEC 13211-1:1995, ..." 7.* describes expansion which happens before execution. This means that any parts of the constructs discussed are just terms. In particular G is a term (representing what will eventually become a goal). "7.15.7 ... if G immediately contains a cut ('!'), this is handled like a grammar-body-cut (cf. 7.15.10)". That sentence can be removed. What does "If G immediately contains" mean in this context, and why does it matter. Surely a construct such as { (true,false;true,!,true;true,false) } does not "immediately contain" a cut in any sensible way but just as surely it will behave exactly like {!}, so why then mention "immediately contain" and grammar-body-cut at all? "7.15.8 call//1" "7.15.8 ... call//1 shall result ... in the goal for the predicate call/3 ..." Should be "... built-in predicate call/3 ..." for consistency with 7.15.9 which has "... the built-in predicate phrase/3 ..." "7.15.9 phrase//1" "7.15.9 ... phrase//1 is a grammar-built-in predicate ..." "grammar-built-in predicate" is not a defined term. "7.15.11 (\+)//2 -- grammar-body-not" "7.15.11 ... (+)//2 is expanded to the principal functor (\+)/1 of a grammar-body-not ..." This makes no sense. Surely nothing is expanded to a functor. "7.15.11 ... This functor (\+)/1 is applied to the expanded argument ..." Functors are not "applied". This needs a rewording. "7.16 Executing procedures expanded from grammar rules" "procedures" are not expanded from grammar rules. Clauses are expanded from grammar rules. "7.16 ... a built-in predicate, existing in the complete database." Is this not redundant? All built-in predicates does exist in the complete database (Subclause 7.5). "7.16 ... When the database does not contain a grammar rule ..." The database never contains any grammar rules. They are expanded to clauses when the program is prepared for execution. "7.16 ... If the error handling of the processor is standard conforming as specified in subclause 7.7.7 ..." This makes no sense. Why would this TR care about processors that are not standard conforming? Subclause 7.7.7 does not specifically distinguish "standard conforming" error handling from other kinds of error handling. Indeed, this TR (or any standard) has no way of specifying the behavior of implementations that are _not_ standard conforming. The point of this TR (and any standard) is to specify the behavior of a standard conforming implementation. (Hmm, perhaps the intended meaning is along the lines of "if the error handling is plain old error handling as in Part 1, then ...; otherwise if the processor supports the standard conforming, clause grammar error extension defined in this TR, then ..."? In that case it needs rewording) "7.16 ... the error term .. shall be: existence_error(procedure, N//A)" This is bad, for at least the following reasons: . it requires the processor to treat procedure calls differently in an "ordinary" clause compared to a call in a clause expanded from a grammar rule. This is an undue burden on the implentation. It is not, as far as I know, traditional behavior. . It places a burden on existing user code that currently expect only N/A predicate indicators. Such code will suddenly mysteriously fail when it tries to process the second argument of the existence_error/2 error term. I do not object to adding N//A in places like export/1 directives as an alias for N/A+2, but I think it would be a very bad idea to suddenly force users to modify their code to handle such terms in places where N/A has been the only expected term for 20 years. Nothing prevents implementors to add this kind of detailed information in the implementation dependant part of error/2 exception terms. "7.16 ... if the ... processor supports definite clause grammar errors, then the error term shall be: existence_error(grammar_rule, N//A)" This is even worse. Now the hapless user needs yet another catch/3 to match yet another possible exception term. Furthermore, there is no way for the user to know whether processor "definite clause grammar errors", e.g. no prolog flag (not that I advocate such a flag). "7.16 ... In other cases ..." The "In other cases" sentence should be removed. What case remains if the error handling is neither standard conforming nor supports definite cause grammar errors"? In this case we do not have a conforming processor and this TR has no mandate or reason to try to restrict its behavior. "7.16 ... NOTES 1 Prolog Processors should report errors resulting from execution of grammar rules at the same abstraction level as grammar rules whenever possible." (should be "... Prolog processors ...") What does this mean exactly. First, it is non-normative so it has no bearing on the standard. Second, what does "report errors" mean? Messages to the user? Exception terms? As I argued above, new exception terms is very bad idea. Obviously it is better if error messages directed at a human is informative, but this is a quality of implementation issue and need not be stated in this TR. "7.16 ... NOTES ... 2 ... subclause 2. Grammar rules are expanded there into Prolog clauses during preparation for execution, ..." This makes no sense. 8.1.1. defines phrase/3 and phrase/2 neither of which expands grammar rules, or is involved during preparation for execution. "8.1.1 phrase/3, phrase/2" "8.1.1.1 Description" This subclause is complete gibberish. I will not bother to comment on what is wrong. I can transcribe my written notes on request, if someone does not agree that this subclause is best rewritten from scratch. "8.1.1.2 Template and modes" "8.1.1.2 ... phrase(+grammar-rule-body, ?comprehensive-terminal-sequence, ?remaining-terminal-sequence)" Where are the types comprehensive-terminal-sequence and remaining-terminal-sequence defined? Surely the arguments are not required to be []-terminated lists neither at call or success. "8.1.1.4 Errors" "8.1.1.4 ... c) S0 is not a terminal-sequence ..." "8.1.1.4 ... d) S is not a terminal-sequence ..." These are clearly incorrect with the current definition ([]-terminated list) of terminal-sequence", e.g. consider a call phrase([],S0,S). "10 Logical Expansion: ..." This section needs an introduction, e.g. to specify to what extent it is normative. "10 ... % ... may be replaced by "iso_phrase" or else." This sounds like a threat. To whom is the statement in the comment directed? It may make sense in some separate source file but it does not make much sense in a standard text. There is still a mixture of (\=)/2 and subsumes_term/2. It would be more consistent to use subsumes_term/2 everywhere. "10 ... dcg_rule(...) " These seem to specify how a grammar rule can be expanded to a clause. However, I do not recall any explicit reference to this procedure in this TR, especially not in normative text. In the following I will quote in a different style, that better fits program code. > dcg_body(...) :- > ... > NonTerminal \= ( _ -> _ ), > ... Why is (->)/2 disallowed as non-terminal? My preference would be to treat (A->B) as ((A->B);{fail}) as is traditional. Also, I object to '|'((A->B),C) not being treated as if-then-else. This is a compatibility concern since this used to work (and, what is worse, unquoted '|' traditionally used to work the same as (;)/2 in plain clauses too...) > % The principal functor of the first argument indicates > % the construct to be expanded. That comment is next to meaningless. A proper description of the meaning of the procedure would probably make it obvious that its last clause does not belong. > dcg_cbody(( GREither ; GROr ), S0, S, ( Either ; Or )) :- > subsumes_term(( _ -> _ ),GREither), > dcg_cbody(GREither, S0, S, Either), > dcg_body(GROr, S0, S, Or). This should use the same variable names as in 7.15.5 (and GBFirst is better than GREither since we are not processing an alternative here). The use of dcg_cbody/4 to process the first argument if the (;)/2 makes no sense since the ( _ -> _) term does not correspond to a control structure (and it has no corresponding clause in dcg_constr/1). Inline the corresponding clause from dcg_cbody/4. > dcg_cbody(( GRIf -> GRThen), ...) :- > ... This clause does not belong. All other clauses correspond to control constructs and are guarded by dcg_constr/1. Regards, Per Mildner Per.Mildner@sics.se Swedish Institute of Computer Science