🚀 go-pugleaf

Forwarded for Roger Scowen -- KRG0@gm.rl.ac.uk
 
RESPONSE TO COMMENTS FROM RICHARD O'KEEFE ON PROLOG STANDARDIZATION
 
GENERAL RESPONSE
 
Richard O'Keefe started by saying that he would respond to the
mailing from Chris Moss. In fact many comments refer
to a document (Prolog syntax, Draft 4.1) that
most news readers (and members of the ISO and BSI panels) will
not have seen.
 
This seems somewhat unfair on readers who will be unable to judge 
whether draft, criticism, or rebuttal is justified.
 
First some general comments. The objective is to define an
International Standard for the programming language Prolog.
This means that standard conforming programs will run correctly
on standard conforming processors, neither more nor less.
It will not limit implementers from introducing new features and
facilities into their Prolog compilers. 
 
Neither will it mean programmers cannot use such extensions; only
that if they do, their programs will not conform to the standard.
 
But a standard will permit people and companies to write applications
and libraries that will run on any conforming implementation
and thus give them a framework in which to work. In particular, such users
and their customers will not be restricted to a single implementation.
A standard will also give teachers, authors and students a common core 
of useful Prolog.
 
Once a feature has been included in a standard, it is almost
impossible to remove. The committee remembers that Fortran has been 
burdened with arithmetic if statements and computed goto statements.
In Prolog we hope to avoid such legacies if possible.
So some features of Edinburgh Prolog will not be in the standard 
because although they fulfilled a need at one time, they are
not a sensible longterm solution.
 
Now some replies to specific criticism.
 
DIVERSITY OF EXISTING PROLOG SYSTEMS
 
>	(4) The basic structure of the BSI approach to syntax has been
>	    to cut the Gordian Goose.  That is, instead of regarding the
>	    (actually rather low) diversity of Prolog syntax as an
>	    opportunity to be solved by making the language more powerful
>	    (e.g. having a table-driven tokeniser), it has been treated as
>	    a problem to be solved by inventing a new, more restricted,
>           language.
 
Well, yes and no. Chris Moss has produced tests that give
different results on every system tested so far. Perhaps there
is rather more diversity than Richard O'Keefe realizes.
One objective has been to define a syntax where many existing 
systems would not generally disagree on the meaning of 
standard-conforming programs. 
 
PROLOG CONTROL STRUCTURES AS SYNTAX
 
>	(3) The attempt to describe Prolog control structures as *syntax*
>	    is fundamentally misdirected.
 
This is a matter of opinion. One reason for regarding Prolog control
structures as *syntax* is so that a person or program reading
a Prolog program can always recognize its overall structure.
 
NOTICE OF MEETINGS
 
>  (By the way, I
>  *do* wish the BSI crowd would send me these things so that they arrived
>  at least a week in advance of the meetings, instead of a day or two
>  afterwards.  I have never yet received notice of a meeting in time to
>  send written comments for the meeting to consider.  I haven't much
>  confidence that they'd be read if I did send them, but it'd be nice to
>  be given the chance.)
 
Meetings are planned and advertised several months in advance,
for example, the following meetings are already planned:
 BSI, London on Thursdays 2nd June, 1st Sept, 1st December 1988.
Any extra meetings to discuss the syntax will be on the previous
day (i.e. 1st June, etc); any meetings to discuss built-in predicates
will be a week later, i.e. 9th June, etc.
Everyone who wishes to attend is welcome. I admit that pressure of
work means that some papers are sent only a week before the meeting.
This is ample for British members of a British panel, but not for 
Californian members. 
But other papers will have been sent four or five weeks earlier.
 
All comments, whether they are received before or after a meeting,
are read and considered.
 
',' and '&' AS OPERATORS
 
> Oddly enough, if one takes the grimoire literally, the user CAN
> declare ',' and '&' as operators, and can use them in that form.
> However, ',' and '&' cannot possibly have the same precedence as
> "," or "&" in BSI Prolog, and it seems clear that (A ',' B) and
> (A '&' B) must be different terms.  
 
It is not intended that it will be possible to declare ',' and '&'
as operators.
 
A MISTAKE IN COMMENTS
 
	/** By L22, this is not a legal comment **/
 
Thank you. This will be a valid comment in standard Prolog despite
the error in this draft.
 
QUOTE OPERATORS USED AS OPERANDS
 
>	compare(R, X, Y) :-
>		( X @> Y -> R = >
>		; X @< Y -> R = <
>		;	    R = =
>		).
 
Richard O'Keefe realizes that the above example is intended to be
syntactically incorrect in the standard. When operators are
used as operands, there many problems of possible ambiguity.
A cure is still under discussion, but some problems are
avoided by the rule that "An operator used as an operand must be
bracketted".
 
AN INFIX CONS OPERATOR
 
> The following clause, valid in Edinburgh Prolog, is illegal in BSI Prolog.
>	append(H.T, L, H.R) :-
>		append(T, L, R).
 
We are still considering the problems posed by the multiple uses of '.',
i.e. as a decimal point, as an infix cons operator, and as a clause
terminator. At the same time we desire to make layout characters
unimportant in determining the meaning of a program.
Several possibilities have been suggested and are under consideration.
 
NEGATION
 
>	not Goal :-		% "not" is not a built-in operator
>	    (	ground(Goal) -> \+ Goal		% neither is "\+".
>	    ;	signal_error(instantiation_fault(Goal,0))
>	    ).
> 
> [The fact that the grammar proper has no negation proper is no accident.
>  The grammar in the grimoire defines only operators with at the level of
>  comma and weaker.  Negation binds more tightly than comma, so it would
>  have to be in the table of built-in operators.  The absence of any
>  negation operator from that table may be a mistake, or it may not.  It
>  may be the intention that one has to write > ]
It is intended that Standard Prolog will not contain 'not' or '\+'.
Standard Prolog will not require systems to implement true
logical negation and it would be misleading to include an 
operator or predicate that implies that they have done so.
Instead the way is left open for processors to implement a version
of 'not' as an extension and still remain standard conforming.
Standard Prolog will contain a built-in predicate 
that implements 'negation by failure', i.e.
      fail_if(G) :- call(G), !, fail.
      fail_if(_).
 
A PARSER AS STANDARD
 
>    In an attempt to make DEC-10 Prolog syntax even more of a de-facto
>    standard than it was, while I was at Edinburgh I wrote a lexer and
>    parser for DEC-10 Prolog, and gave them away free.  I still do; at
>    SLP87 the lexer was one of my examples.  Quintus Prolog, SICStus
>    Prolog, and SB Prolog all use read/1 predicates based on the parser.
>    (There are lexical differences between SB Prolog and the others,
>    but not syntactic differences.)  I have heard of other Prologs which
>    use this parser, but have no confirmed names.
>
>    The BSI committee should do the same.
 
A program that resolves ambiguity implicitly is not acceptable as
defining a standard; there must be further definition.
One reason is that a program specifies too much. Some features need to
remain 'implementation dependent' because we must not specify
them, for example: the accuracy and largest values of floating point
numbers, or the integer value corresponding to a character.
 
Another reason is that it is harder to understand and find errors.
 
DISCLAIMER AND CONCLUSION
 
Never rely on working papers and draft standards. They are subject to
changes and review. All documents and working papers, however
confidently expressed, are also subject to review. There will be no
standard until the member bodies of ISO have approved it.
 
The next working drafts will incorporate changes arising from further
consideration and the comments received (including those from
Richard O'Keefe).
 
Many countries, but not at present USA, have national Prolog panels
coordinating their views on the emerging standard. I encourage all 
Prolog implementers and users to participate in this effort in order that
the eventual standard is one that preserves the best of the past
and also provides development paths for the future.
 
Roger Scowen, 11 March 1988