ISO/IEC JTC1 SC22 WG17 N257
Comments on N253 2014-04-08, WDTR 13211-3

Ulrich Neumerkel, 2014-06-12
Remark on the timeliness of these comments: The new DIN draft was scheduled for 2013-11-15 (Istanbul Resolution A4) but appeared 5 months later which reduced considerably the time for comments.

Comments on previous versions: N218 2010-04-01, N218 2010-07-18, N232 2012-07-13, N238 2012-11-20. N249 2013-08-20. While there is some progress compared to N249, there are still many open issues, and the previous comments must still be taken into account.

  1. 7.14.2 Replace SemiContext by Semicontext. It is one word like semigroup.
  2. 7.14.3 Semicontexts replace by Semicontext (it is 7.9.4 cut and not cuts, 7.8.5 conjunction etc)
  3. ...as an optional second argument ... . A semicontext is not an argument.
  4. ... after successful application of the grammar rule... This is an operational description.
  5. 7.14.3.2 Examples: nt(S0, [word|S]) :- S0 = S. should read nt(S0,S) :- S = [word|S0]. or introduce further equations.
  6. 7.15: Many of the comments of N249 2013-08-20 have not been integrated: In particular, there is no presentation comparable to 7.8 Control constructs. Also, it is not visible which cases are considered implementation dependent. There are still far too many enumerations. In fact only two are needed the concrete constructs 7.15.1 etc and the reference implementation.

    Since, there has not been any attempt to define when constructs are well defined and when they are implementation dependent, maybe the best would be to define this formally only.

  7. 7.15.2 ('|')//2 - list separator. This has to be '.'//2.
  8. 7.15.4 (;)//2 - alternative. Here, the special case of if-then-else has to be mentioned similarly to 7.8.6.
  9. 7.15.5 ->//2 - if-then-else. This is an if-then, not an if-then else. If-then-else is (;)//2. The remarks make this somewhat clear, but the present form is unsuited for a definition.
  10. 7.15.6: ( a -> b | c) needs to be implementation dependent.
  11. 7.15.7: ... If G immediately contains a cut, ... This needs to be clearer that cuts within {}//1 extend outside of {}//1.
  12. 7.15.9: phrase//1: There is a further use: a single variable Goal is expanded to phrase//1 and respectively phrase/3.
  13. 7.15.11: (\+)//1: It seems the entire construct is rather disputed: At least it should be left as a dummy that must not be used otherwise.
  14. Cases like
    [] --> [a].
    \+ a --> [].
    a --> [_|_].
    a --> (b --> c).
    a, b --> c.
    ! --> [].
    
    Must be left implementation dependent. But where is this defined?
  15. Should (\+)//1 be retained, the rule for (\+)//1 would be rather:
    dcg_cbody(\+ GRBody, S0, S, ( \+ phrase(GRBody,S0,_), S0 = S )).
    
    Implementations still may translate things more efficiently, however, the observable semantics, particularly with respect to cuts and errors must be retained. As an example, consider the query phrase(([a],\+1),[]) which always should fail and not produce an error.
  16. Renumber 8.1 to 8.18 (again!)
  17. Added 2014-06-27: The original DECsystem 10 manual of 1978 read: (Similarly SICStus) A grammar rule takes the general form:-
                        LHS --> RHS.
    
    meaning "a possible form for LHS is RHS".

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

Validated HTML