🚀 go-pugleaf

This still isn't the detailed comments, but my claim in article <736@cresswell>
that
>	(3) The attempt to describe Prolog control structures as *syntax*
>	    is fundamentally misdirected.
warrants an example.  I am referring to document BSI/IST/5/15
ISO/IEC JTC1 SC22 WG17 "Draft for comment: Feb 1988".  (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.)

Here is the example.  In Prolog as we know and love it:
	p :- q.
and
	(p :- q).
are both clauses, and they are identical as clauses.  This is true
even in BIM Prolog's rather original native syntax.  (There, Bart
Demoen, I mentioned BIM Prolog!)  Well, in BSI Prolog, they are both
clauses, but they are *different* clauses.

By rule 2.2 of BSI/IST/5/15 (henceforth to be called "the grimoire"),
	p :- q.
is a clause which means whatever
	sys(procedure,[func(p,[]),func(q,[])])
means.  {What *does* it mean?  Ah, that's another story.  I don't know
either.  The grimoire doesn't say.}

Rule 2.2, by the way, looks like this:

2.2		clause		=		term, ":-", body ;
Constraint	X				X	    g
Abstract	sys(procedure,[Head,Body])	Head	    Body

This means something like
	clause(X, sys(procedure,[Head,Body])) -->
		term(X, Head),
		[:-],
		body(g, Body).
The grimoire does say a little bit about the "Abstract" line, but it
leaves the "Constraint" line completely unexplained, and I'm sorry but
I can't tell you what it means, because I don't know.

Back to the point.
	p :- q.
is a clause which stands for something which looks pretty much like a
clause.  Now for
	(p :- q).
By rules 5.5 and 2.1, this is a clause, which means whatever
	sys(procedure,[sys(procedure,[func(p,[]),func(q,[])]),func(true,[])])
means.  That is to say,
	(p :- q).
is identical to the clause
	(p :- q) :- true.

Well, that's a bit surprising.  What about
	:-(p, q).
which in Edinburgh Prolog is identical to the other two examples.

Let's look at rule 5.4.

5.4	   term          = atom, (next bracket | sep bracket), termlist, ")" ;
Constraint h
Priority   0
Abstract   func(Name,Args) Name					Args
Condition					not prefix_op(Name)

[I replaced 'close bracket' by '")"' to fit the rule on one line.
That's what it means anyway.]

There's a language change in here, rather a deplorable one, I think.
Evidently, someone with power on the committee believes that the
happy marriage between function symbols and their left parentheses
should be split up.  The first time I read this rule, I interpreted
it as meaning that a function symbol could not be a prefix operator,
which would make :-(p,q) illegal.  It was a wee while before it dawned
on me that while spaces inside Prolog are being attacked, spaces inside
the standard are sacred!  (The grimoire doesn't say so, but that's the
only way of making sense of some other rules as well.)  The rule actually
says that function symbols can be divorced from their parentheses *unless*
they are prefix operators, in which case parting asunder is *out*.
The Edinburgh Prolog rule was very simple:
	there is *never* layout between a function symbol and a "("
	there is *always* layout between a prefix operator and a "("
The new rule seems very confusing to me.  Pointless too.

Any rate, when I had corrected my misunderstanding, it became clear that
rules 5.4 and 2.1 together mean that
	:-(p, q).
means whatever
	sys(procedure,[
		func(:-,[func(p,[]),func(q,[])]),
		func(true,[])	])
means.

So, three formerly identical versions of a clause
	p :- q.
	(p :- q).
	:-(p, q).
all mean something different in BSI Prolog.
[It is possible that a later stage of interpretation may make
 :-(p, q) and (p :- q) identical, but they would still be identical
 to (p:-q):-true, not to p:-q.
]
This difference, which I am sure was unintentional, flows naturally
from the attempt to treat Prolog control structures as syntax in the
same sense that they are syntax in Procrustes (sorry, in Pascal).

The grimoire makes it plain that
	A , B
and	A & B		<--- BIG MISTAKE
are both mapped to sys(and,[A,B]), but whether either of these is the
same as ','(A,B) or '&'(A,B) is not said.  If we take the "Abstract"
lines seriously, it would appear that ','(A,B) and '&'(A,B) are
distinct terms, neither of which is the same as (A,B) or (A&B).
{Note that &(a,b), legal in Edinburgh Prolog, is NOT legal in BSI Prolog.}

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.  

The grimoire makes it plain that
	A ; B
and	A | B		<--- DEC-10 Prolog mistake retained in BSI Prolog
are both mapped to sys(or,[A,B]), but whether either of these is the
same as ';'(A,B) or '|'(A,B) is not said.  If we take the "Abstract"
lines seriously, it would appear that ';'(A,B) and '|'(A,B) are
distinct terms, neither of which is the same as (A;B) or (A|B).
{Note that ;(a,b), legal in Edinburgh Prolog, is NOT legal in BSI Prolog.}

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.

Note that in
	( a ';' b, c )
the grouping, if it is legal at all, MUST be
	( (a ';' b) , c )
in BSI Prolog.

What about the "then" operator "->"?  Well, unlike ",", "&", ";",
and "|", "->" is an atom.  (In Edinburgh Prolog, "&" and ";" are
both perfectly ordinary atoms, but we are talking about BSI Prolog,
where they are punctuation marks.)  But rule 3.4 is

3.4	   condition = goals, "->", ( goals | condition ) ;
Constraint X		X
Abstract   If,Then	If		Then	Then

which matches up with

3.2	   body               =	          condition, ";", body ;
Constrant  X				  X		  X
Abstract   sys(ifthenelse,[If,Then,Else]) If,Then	  Else
[I've replaced 'or symbol' by '";"', "|" is also allowed.]

It seems quite clear from this that
[a]	( p -> q ; r )
means
	sys(ifthenelse,[func(p,[]),func(q,[]),func(r,[])])
but that
[b]	( p '->' q ; r )
[c]	( ->(p, q) ; r )
if legal, must mean
	sys(or,[func(->,[func(p,[]),func(q,[])]),func(r,[])])

Now, rule 3.4 may be overly precise.  The intention may have been

3.4'	   condition = goals, atom, ( goals | condition ) ;
Constraint X		X     
Abstract   If,Then	If    Name    Then    Then
Condition		      Name=(->)

which would make [a] and [b] identical, but leave [c] different.
A similar intention may exist in rules 2.2 (:-), 2.3 (?-), 2.4 (:-),
and 2.5 (-->) where the quoted items are also legal atoms.  But
that's *not* what the grimoire actually says!

There's something strange about the treatment of "{" and "}" in BSI
Prolog.  According to the grimoire (rule 5.6),
	{ X }	means	pred('{}',[X])
while	'{}'(X)	means	func('{}',[X])
and	{ }	means 	'{}'
while	'{}'	means	func('{}',[])
This may be an oversight, as may the fact that while
	( p ; q ), ( p :- q ), and { p ; q }
are all legal in BSI Prolog,
	{ p :- q }
is NOT.  (It is legal in Edinburgh Prolog.)

I'm quite sure that the fact that rules L7, L29, L30, and L15
imply that <)> is a valid token is a mistake, but I just thought
I'd mention it.  Another probable glitch is the fact that the
only way to get a backslash character in a quoted atom is to
write its octal code.  (According to rule L12, \\ is NOT a legal
escape sequence.)  A complaint here:  if character escaping is
supposed to be C-like, is it too much to ask that it should *BE*
C-like?  The ANSI C escape sequences
	\a	(audible alarm)
	\v	(vertical tab)
	\\
	\?
are completely missing.

The following clauses, valid in Edinburgh Prolog, are illegal in BSI Prolog.

	/** By L22, this is not a legal comment **/

	compare(R, X, Y) :-
		( X @> Y -> R = >
		; X @< Y -> R = <
		;	    R = =
		).

	:- op(600, xfy, .).	% yes, THIS is illegal.

	append(H.T, L, H.R) :-
		append(T, L, R).

	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 \+(Goal).
]

If we take the lexical rules (specifically L0,L1,L2) and rule 0 of
the grimoire literally, any program containing a comment is illegal.
The lexical rules very clearly classify comments as tokens, and as
clearly return ALL the tokens, and rule 0 takes ALL the tokens and
feeds them to the grimoire rules.  There is nothing in the grimoire
which says that comments are dropped!  (If you are interested in
seeing a grammar where this sort of thing is done *right*, I suggest
that you look at
	The Turing Programming Language, Design and Definition.
	R.C.Holt, P.A.Matthews, J.A.Rosselet, & J.R.Cordy
	Prentice-Hall 1988
	ISBN 0-13-933136-0
	US$ 27
I don't like the programming language at all; but I admire they way
they went about defining it.)

With all due respect, may I suggest something to any members of the BSI
committee who may be reading this newsgroup?

    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.

There are two reasons for this.  The first is that anybody can get a
usable Prolog system *free* which is much more compatible with DEC-10
Prolog than anything the BSI committee have ever suggested, and this
Prolog system is superior to BSI Prolog in every other way too.  BSI
Prolog has to provide at least this much leverage:  someone who wants
to switch from ALS Prolog to SB Prolog or Quintus Prolog Prolog has very
little to do, but switching over to BSI Prolog will require a lot of
work.  If there is a free implementation of BSI syntax, as there is of
Edinburgh syntax, that will considerably facilitate the conversion.

But the second reason is more important.  The BSI committee should get
the bugs out of their grimoire as early as possible.  Actually writing
a program and running both the old DEC-10 Prolog library and a large
collection of random data through would help a lot.  It has taken me a
lot longer to type this message than it took me to find the problems I
have listed above, but a computer has better proof-reading skills yet!

The BSI committee started work in 1984.  I know that it takes a day to
get a DEC-10 Prolog lexer written and tested.  Does it really take a
comittee over three years to get this far?  Would it have taken that
long if they hadn't decided to design their own language?  At the Boston
Logic Programming conference, Frank McCabe assured us that the standard
would be ready the following year.  What a good thing it wasn't, eh?