cdsm@doc.ic.ac.uk (Chris Moss) (03/04/88)
I realised recently that many people who've commented about the Prolog
standard have never actually read it. I'm therefore posting a description
of the latest proposal--it only covers syntax, but that is what most
people get worried about first of all! It is much closer to "Edinburgh"
than some previous proposals, but does try to regularize some of the
obvious defects. (The S-Expression syntax isn't covered here; if you want
to know about it, ask!)
--------------------------------------------------------------------------
The following is a brief description of the syntax proposed for the Prolog
standard. It is designed to clarify the syntactic issues by concentrating
on the points of difference between it and other implementations rather
than introducing it for those with no experience of the language. It
should be readable by users of any current dialect of Prolog. It does not
in general attempt to justify the choices: for this refer to the issue
sheets.
Prolog uses a number of rather arbitrary symbols for "if", "and", "or",
etc. By and large the standard follows those used by the most widely
copied implementation: DEC-10 Prolog from Edinburgh.
e.g. likes(rabbit, mole).
likes(rabbit, owl) :-
likes(owl, rabbit)
; obeys(owl, rabbit),
helps(owl, rabbit).
i.e. if is ":-", and is ",", or is ";" and the clause terminator is ".".
The alternative symbols '&' and '|' may be used for 'and' and 'or'
respectively and are mapped into the same symbols if used in a term. Thus
the clause above may be written:
likes(rabbit, mole).
likes(rabbit, owl) :-
likes(owl, rabbit)
| obeys(owl, rabbit) &
helps(owl, rabbit).
To indicate variables, two conventions may be used: a variable may start
with a capital (large) letter or the character "_" (underscore) and it may
contain any other digits or letters or underscores. Thus A, Person,
_person, _123 and _1_2 are variables, but *A, t-lit and _one-more are not.
Lists use exclusively the square bracket convention: [a,b,c] is a proper
list and [a,b,c|X] is a list of which the fourth member is a variable. For
reasons stated below, a.b cannot be written in the language, though the
cons pair [a|b] unifies with the normal functional term '.'(a,b) (i.e. the
functor of a list is '.').
An atomic symbol may always be placed in single quotes (e.g.
'an-atomic-symbol') but the two most common ways of writing it use no
extra marks: an identifier starting with a small letter and consisting
only of letters, digits and the symbol "_"; and a graphic symbol composed
of any number of other symbols excluding those (e.g. ()][,;) used for
special purposes in the syntax. Thus +, //, <=> are all graphic symbols
which can abut directly to identifiers and special symbols such as ",".
For historical reasons, ! is a special symbol, so the sequence :-!. is
treated as three symbols not one, though ! is an atom not a punctuation
mark.
The status of "." is special. It is the clause terminator and thus has a
key role in parsing and error recovery, and also occurs in real numbers.
However it can be used in graphical symbols as long as it does not appear
alone (e.g. in =..). In many implementations, the clause terminator is
identified by the presence of white space (space/new line) after it, so
that (with appropriate declarations) the sequence a(b).c(d). is
interpreted as a single clause with principle functor '.' (which is, as
noted above, the list functor). In standard Prolog the presence or absence
of white space has been reduced as far as possible, so this distinction is
not made. A consequence of this is that the infix dot notation for lists
is not available, which anyway has ambiguity problems when real numbers
are considered (consider 1.2.3.4).
Operators may be declared in a way that is close to that provided in
DEC-10 Prolog. This does not apply to the level of system operators such
as ',' and ';' which are fixed in the syntax and cannot be changed. The
aim of this is to allow better error detection and reporting than is
possible in a fully general system. Prefix, infix and postfix operators
may be declared but the combination of operators that may be declared has
been limited so that the parsing of any expression is unambiguous and may
be parsed without backtracking. The rules that ensure this are as follows:
1. A right-binding operator binds more strongly than a left-binding
operator with the same declared priority number.
2. A symbol which has an operator declaration in force may not be used as
the operand of an expression though it may appear as an isolated symbol.
e.g. "a + +" is illegal, though the 'normal' form of this expression as
it is interpreted by DEC-10 Prolog, +(a,+), would be allowed.
3. If a prefix operator appears before an open bracket symbol it must be
separated by clear space otherwise it will be interpreted as the normal
functional form. This only affects the interpretation of a few expressions
and one is not bound in general to place a functor next to its opening
bracket. Thus the common practice of leaving a space between function or
predicate symbol and opening bracket is allowable, unless there is a
prefix declaration for the function symbol. In the latter case the
interpretation will be identical if there is only one argument, but
- (a,b) would be interpreted as -(','(a,b)).
4. One cannot have two operator definitions for the same symbol current at
the same time, with the exception of combination of the pair: prefix and
infix. This is to allow the such uses as unary minus, which are firmly
embedded in mathematical notation.
The effect of these rules is that it is impossible to construct any
ambiguous expressions and all Prolog implementation will interpret every
expression the same.
The notation for operator declarations is, as currently proposed, similar
to DEC-10 with the exception that only operators in the range 0-999 may be
declared. i.e. 999 is the least binding, or most dominating, and 0 is the
most binding or "highest priority" or "first to be applied". Prefix infix
and postfix operators are represented by the symbols fx, xfx, and xf
respectively for non-associative operators and fy, yfx, xfy and fy for
associative operators. Other notations have been proposed but do not seem
preferable for other than stylistic reasons, and style has generally been
subordinated to common practice in formulating the standard.
Strings are represented in a program between double quotes, but a "C"-like
convention has been adopted for special characters. e.g. "\n" represents a
newline symbol and "\"a quotation\"" represents a string which includes
the quotation marks. The semantics of strings are different to DEC-10; a
string is a separate data type which does not unify with atoms or lists
and several built-in predicates are provided to process them efficiently,
including converting them to lists of small integers. The advantage of
this is the freedom allowed to the implementer to provide efficient
storage and manipulation of longer strings (atoms have a limited length).
There is also an "S Expression" Syntax proposed, which is not dealt with
here. This is designed to be compatible with normal LISP usage, but
mapping semantically into the same structures so that programs may be easily
transferred from one syntax to the other.
----------------------------------------------------------------------------
Chris Moss. March 1988.dave@quintus.UUCP (David Bowen) (11/10/89)
In article <2643@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes: >The internal politics of WG17 are quite irrelevant. >The point is, *I* don't get a vote. Lee Naish doesn't get a vote. Rick >Muggridge doesn't get a vote. The team at HP don't get a vote. >Virtually *all* of the people who are using Common Prolog systems (that >is, virtually all of the people who will be affected by WG17) have no >representation at all. The Swiss are pushing for this and the French >are pushing for that (according to N40 they want variables to begin only >with underscores), but many nations are not represented at all (there is >no New Zealand representation, for example), but it isn't REALLY "the >Swiss" or "the French" but the particular people who managed to get >themselves appointed as national representatives. Having recently attended my first WG17 meeting, as a U.S. delegate, I think I should comment on this. If there are people in Australia and New Zealand who care about the Prolog standard, they should consider trying to get their official national standards bodies to nominate delegates to WG17. The usual problem with this is that the delegates have to be able to put the necessary time into the work, and their employers have to be willing and able to pay to send them to meetings. Those who are not able to get direct representation through their national standards organization should not give up. Since the standardization process works by consensus, one vote more or less is not usually the issue. What really matters is convincing people. Possible avenues for doing this are writing to this net or sending "personal contributions" to Roger Scowen, the convenor of WG17. Roger's address is International Organization for Standardization National Physical Laboratory Teddington, Middlesex U.K. Personal contributions are distributed by Roger to the members of WG17 and other interested parties, and they are discussed the next time that the working group meets. (Meetings are held every 6 months or so; the next one is scheduled for April.) To be most effective, contributions should be concise, clear and constructive. Long diatribes which defame the morals and the competence of the members of the committee are counter-productive. >Let's be honest about this: democracy is rule BY the same people >who are affected. Some of us (like me) can't vote for a representative >even in principle. Those of us who belong to countries which are >"represented" did not get any opportunity to pick their "representatives". This last statement is not true in general. In the U.S., at least, the future delegates to WG17 will be chosen by the ANSI working group on Prolog standardization. Membership of this working group is open to anyone who lives in the U.S., or works for a U.S.-based organization, and is able to attend the meetings. This group has not really got started yet: there was an ad-hoc meeting of interested people at IJCAI in August. The first real meeting is expected to be in Washington D.C. in January or February. Information about this meeting will be posted on the net. >The one and only >legitimate concern of the committee is to standardise the Prolog >programming language more or less as it stands. What Prolog _is_ is >not a matter for philosophy, but for empirical investigation. I totally agree with this and also think that it is a valid criticism of the work done by the committee so far. I think that there is a tendency to argue about what is the "right" feature in order to get away from people simply arguing for standardization of their own favourite Prolog dialect. From this point, it is very easy to inadvertently cross the dividing line from standardizing to designing a language. On the other hand, standardization *entirely* by empirical investigation is not practical. Would we standardize on whatever is used by the largest number of people? Would we include Turbo Prolog? >The people on the committee get paid to do what they >do. I have not. I've put a couple of weeks' work into reading and >commenting on stuff this year, all of it unpaid. As far as I could tell, most of the people on the committee are actually paid mainly to do other things than standardize Prolog. Generally speaking, it is a background activity, presumably because employers do not think it sufficiently important to be a full-time job. I think that this is a problem, and it is the main reason why Richard has been able to point out so many inconsistencies and errors in the draft standard. Maybe it means that it is still too early for a Prolog standard. WG17 is going to carry on anyway. For WG17 to start doing a better job, as Richard wants, we need more people to do more work. I hope that we can get together a vigorous ANSI group and so have a substantial influence on WG17. We need more Prolog users to get involved - these days the standardization effort is heavily weighted towards Prolog implementors. And I hope that Richard will get involved, as a consultant to Quintus, in helping to forge an ANSI position. We don't yet have any mailing list organized for the ANSI working group. I suggest that for the time being we use comp.lang.prolog for discussion of standardization issues.
ok@cs.mu.oz.au (Richard O'Keefe) (11/10/89)
In article <1281@quintus.UUCP>, dave@quintus.UUCP (David Bowen) writes: > Richard O'Keefe wrote: > >Let's be honest about this: democracy is rule BY the same people > >who are affected. Some of us (like me) can't vote for a representative > >even in principle. Those of us who belong to countries which are > >"represented" did not get any opportunity to pick their "representatives". > > This last statement is not true in general. In the U.S., at least, the > future delegates to WG17 will be chosen by the ANSI working group on Prolog > standardization. Membership of this working group is open to anyone who > lives in the U.S., or works for a U.S.-based organization, and is able to > attend the meetings. In fairness to Roger Scowen and the others, I should make it clear that I did have the opportunity to be on the BSI committee: starting shortly after I left the UK. Now that I've left the USA, there's an ANSI committee. Perhaps I should leave some more countries... Dave Bowen's last sentence appears to say that USA citizens & workers can have some say in who represents them on WG17 _if_ they are rich enough. "Put your money where your mouth is" is a reasonable criterion, but it is not what we call "democracy". I do not claim that WG17 *ought* to be a democracy; that criticism was a response to another posting. Let's compare this with the C and Fortran 8X standards. The C standard was developed as an ANSI standard. You could become an "observing member" by paying a fairly modest sum (I think it was about US$100) and this meant that you got copies of the documents (that was a really worthwhile investment, because buying a copy of the draft from Global Engineering Documents cost about US$70 in California, and there were several drafts). However, that didn't get you representation. To have a voice on the committee, you had to pay rather more money, and you had to go to the meetings. The result is that a lot of small companies like Quintus just had to trust X3J11 to do the right thing, yet C is _vital_ to Quintus' operations. Fortunately, X3J11 took it as a firm rule not to break working code if they could possibly help it, and when I left Quintus at the end of last year it was clear that ANSI C was not going to hurt Quintus one little bit. The X3J3 team working on Fortran 8X were similarly determined not to break any aspect of Fortran 77 -- that meant some rather contorted, not to say unpleasant, syntax in Fortran 8X. There is a lot of fear and fury about Fortran 8X, but the worst anyone has been able to claim with respect to old code is that new compilers are likely to be slow and buggy and to generate slow code, which one would expect no matter what 8X looked like. One of the most serious charges against X3J3 has been that copies of the draft standard were expensive. If the standard were being developed entirely by an ANSI committee, or if WG17 delegated the task to an ANSI commitee as was done with X3J3, I for one would have no apprehension about the result. ANSI committees in the past have done a pretty good job of heeding letters from the public. But that is not the way it is being done. One thing which could be a big help in making the development of the Prolog standard accessible to Prolog users generally would be setting up a computer in the USA (and ideally one in Europe and one in Australia and one in the Near North (ok, the Far East for most of you)) to act as a distribution point for current drafts of the standard. This is not a heck of a lot of work: the mail server "netlib" software already exists and can be picked up free. The main work required is the work of putting the documents in machine-readable form, which is a good idea anyway as it would make them easier to proof-read, index, and otherwise work on. Then publish the E-mail addresses of the server sites in SIGPLAN Notices and the Logic Programming Newsletter and comp.lang.{prolog,misc}. (I did suggest this in 1984, having been able to check Ada questions on UCSC-ECLB. Great idea.) I'm sure that sites could be found which would volunteer to do this if the drafts and comments were made available to them in machine-readable form. It has to be made easy for people to find out what the state of the standard is and cheap for WG17 to tell them, and that seems like a good way.
ok@cs.mu.oz.au (Richard O'Keefe) (11/10/89)
I wrote >The one and only >legitimate concern of the committee is to standardise the Prolog >programming language more or less as it stands. What Prolog _is_ is >not a matter for philosophy, but for empirical investigation. In article <1281@quintus.UUCP>, dave@quintus.UUCP (David Bowen) writes: > I totally agree with this and also think that it is a valid criticism of > the work done by the committee so far. ... On the other hand, > standardization *entirely* by empirical investigation is not practical. > Would we standardize on whatever is used by the largest number of people? > Would we include Turbo Prolog? If we standardised on whatever was used by the largest number of people, we'd probably pick DBASE III. The original terms of reference for the BSI committee had them promising to develop something like what Clocksin & Mellish described; it is only _necessary_ to investigate Prologs which are "Clocksin & Mellish compatible". (Which certainly means PopLog, by the way.) However, it would be wise and courteous to look at other Prologs. One of the documents I wrote in 1984 was a study of Waterloo Prolog, which is not C&M compatible, and the document showed that the evaluable predicates I had previously proposed weren't quite enough to support a Waterloo compatibility package, and suggested a few more which would get you most of the way. So my own opinion on this is YES, someone on WG17 *SHOULD* look hard at Turbo Prolog, and should write and distribute a document which at least outlines how Turbo Prolog programs can be converted to WG17 Prolog. It's not necessary to include Turbo's types and modes in WG17 Prolog. However, I believe that Turbo Prolog has strings of a sort, and that being so, that is one of the most powerful arguments I know why WG17 Prolog should have strings. (I detest strings -- they are not at all an efficient way of handling text. Come to that, I detest Turbo Prolog. But the people who bought it deserve _some_ consideration.)
dave@quintus.UUCP (David Bowen) (03/13/90)
X3 ANNOUNCES FORMATION OF A NEW TECHNICAL COMMITTEE,
X3J17, PROLOG,
TO DEVELOP AN AMERICAN NATIONAL STANDARD FOR
PROGRAMMING LANGUAGE PROLOG
Washington, D.C. -- Accredited Standards Committee X3,
Information Processing Systems, announces the formation
of a new Technical Committee X3J17, Prolog.
The Prolog programming language has become firmly estab-
lished worldwide, with implementations on all sizes and
types of computers. A standard needs to be developed
establishing an abstract and concrete syntax for the so-
called "pure logical core" of the language, along with
model-theoretic and operational semantics as needed. In
addition a common set of built-in routines and a set of
"extra-logical" and "non-logical" extensions to the pure-
core should also be specified.
Technical Committee X3J17, Prolog, is being formed to
address these issues, and to participate in the interna-
tional working group on Prolog, JTC1/SC22/WG17. The
intention is to participate in developing an acceptable
international standard and to adopt it as an ANSI
standard.
The first meeting of Technical Committee X3J17 will be as
follows:
Starting date and time: 10 AM April 25, 1990
Ending date and time: 5 PM April 26, 1990
Location: X3 Secretariat/CBEMA
Suite 500
311 First Street, NW
Washington, DC 20001
For further information, please contact the Convenor of
X3J17 or the X3 Secretariat, as follows:
Dr. Walter G. Wilson Mr. Jean-Paul Emard
X3J17 Convenor Director, X3 Secretariat
T.J. Watson Research Center Suite 500
P.O. Box 704 311 First Street, NW
Yorktown Heights, NY 10598 Washington, DC 20001
Tel.: (914) 789-7869 Tel.: (202) 626-5740
OR send e-mail to dbowen%quintus.com@sun.com
AGENDA FOR MEETING
__________________
o Wed, 25th:
- 10.00 - 12.00 Introduction to X3, SPARC procedures
- 12.00 - 1.00 Election of recording secretary
- 1.00 - 2.00 Lunch
- 2.00 - 3.00 Overview of ISO issues: Modules, I/O,
Strings, Unification of non-finite terms
- 3.00 - 6.00 Modules, consult
o Thursday 26th:
- 9.00 - 12.00 I/O, strings
- 12.00 - 1.00 Lunch
- 1.00 - 2.00 Misc
- 2.00 - 4.00 Planning, election of other officers
SUGGESTED HOTELS IN WASHINGTON
______________________________
(10 min walking distance from the meeting location)
Quality Inn Capitol Hill
415 New Jersey Av
NW 20001
Tel : (202) 638 16 16
Hyatt Regency Washington
400 New Jersey Av
NW 20001