Comments on WDTR 13211-3:2013-08-20

Ulrich Neumerkel, 2013-01-11

1. Renumber 8.1 to 8.18
2. 10 Logical expansion:
3. 7.15 Grammar control constructs: This should be more similar in presentation to 7.8 Control constructs. And in sync with the reference implementation. Many properties are shared between control constructs. All these properties need to be stated in advance. Eg.: Attempts to define a control construct like

   [] --> [a].

   are implementation dependent. However, such a definition, should it be accepted to be prepared for execution, must in no way influence the meaning of a grammar. Conversely: An implementation that changes its meaning by such a definition is not conforming.
4. The control constructs need subclauses:
   1. Description - here a uniform wording is needed. In 7.8 it was "is true iff". If reference to a control construct's arguments is necessary, the control construct should be mentioned explicitly. E.g for {}//1 - external goal there should be the mentioning of {G} first, only then can G be used.
   2. Template - including the mentioning of a predefined operator
   3. Errors
   4. Examples
5. '.'//2 - is missing as control construct. The current document does not clarify that a rule

   a --> [_|_].

   is implementation dependent.
6. ('|')//2 - alternative does not have the same meaning ; because (->)/2 is not defined. Also, it is not an operator. Even if there is no operator '|', '|'([],[a]) is still defined.
7. 7.15.4 (;)//2 - it is unclear that it is necessary to insist that (;)//2 has to be expanded to (;)/2. After all, the precise translation is left open. Only the behavior is defined.
8. 7.15.5 again too much detail in the translation and insufficient detail for the construct and its meaning.
9. 7.15.6 {}//1 - extra conditions: "is not subject to expansion". this is misleading, an appropriate template and mode e.g. phrase({goal},?list,?list) or similar would clarify the situation. Also, a remark on the effect of cut is needed!
10. 7.15.7 phrase//1 - this is the analogon to call/1. For the meaning, no reference to an expansion is needed.
11. p.19 before 7.16: This paragraph should go into 5.5.x! Here it is entirely unmotivated.
12. 7.16 existence_error(procedure,N//A) - this seems overkill. A message system can reconstruct the actual meaning with other means if needed.
13. 7.16 the reference to the database needs to go in another place before 7.15.
14. 8.1.2 expand_term/2. It is controversial whether or not this should be defined. What exact expansion should it provided? There are a lot of implicit implications lingering here. For example: This insists that an expansion must be rule-to-clause wise.
15. 10.1.1 term_expansion/2: why define this at all? DCGs may be implemented this way, but this is irrelevant, since an implementation has to be provided by the system. Compared to expand_term/2 this is even more controversial.
16. Missing: Where is it stated that inserting a new nontermial 'phrase([])' or 'epsilon' does not change anything?
17. Semantic issues:

    ?- phrase([a,b],[c|S],S).

    this is currently STO. Note that also

    ?- [a,b|S] = [c|S].

    is STO! Some "sequencing" is necessary should this be made NSTO.

Other DCG documents

Related topics on SO

1. Standard way to see what phrase/3 translates
2. DCG Expansion: Is Steadfastness ignored?
3. DCG for idiomatic phrase preference