🚀 go-pugleaf

In reply to: ok@quintus.UUCP (Richard A. O'Keefe)
rok>This still isn't the detailed comments, but my claim in article <736@cresswell>
that
cdsm>	(3) The attempt to describe Prolog control structures as *syntax*
cdsm>	    is fundamentally misdirected.
rok>warrants an example.  I am referring to document BSI/IST/5/15
rok> ISO/IEC JTC1 SC22 WG17 "Draft for comment: Feb 1988".
rok> 
rok> Here is the example.  In Prolog as we know and love it:
rok> 	p :- q.
rok> and
rok> 	(p :- q).
rok> are both clauses, and they are identical as clauses.  
rok> Well, in BSI Prolog, they are both
rok> clauses, but they are *different* clauses.

WRONG. The second is not allowed in the BSI form. You missed the 'h'
constraint. -- Before you point it out, there are a couple of errors in
these constraints. The version-to-be-published (the one you had is
basically for the committee) will correct it!

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

Oh dear. The first three times I read that, I saw:
	:- (p, q).
and thought you were talking about bracketted 'and' clauses.
And that is precisely the point. 
In English, and in most programming languages post-Fortran, spaces are
used to separate symbols which would otherwise run together. In this case
they are used for an entirely different purpose: to distinguish two
different uses of the symbol "(". Now it is a fact that most of the
typists I've ever asked to type up Prolog programs put spaces between a
predicate and its arguments
e.g.	funny ( idea ).
as do many logicians and programmers. 
(flame on)
      WHY THE HELL SHOULDN'T THEY??
(flame off!)

The reason is of course that the authors of Edinburgh Prolog thought up a
very clever way to distinguish normal form functions from prefix operators.
This means that one doesn't have to use quotes to distinguish operators in
most contexts, but can get into the weirdest messes otherwise.
In previous versions of the syntax there were two proposals: the other was
to use quotes to disable operators as is done by several systems (can I
mention BIM-Prolog too?). This got so much flack that we've attempted to
move nearer the Edinburgh approach, to the extent that spaces ARE still
important in one context: in "- (A)", the minus is a prefix operator and
in "-(A)" it is a function symbol (they mean the same anyway). But
everywhere else they are optional. I think that's an improvement.

rok> Let's look at rule 5.4.
rok> 
rok> 5.4	   term          = atom, (next bracket | sep bracket), termlist, ")" ;
rok>   The first time I read this rule, I interpreted
rok> it as meaning that a function symbol could not be a prefix operator,
rok> which would make :-(p,q) illegal.

You still haven't got the idea. :-(p,q) is illegal because there's no way
to get it into the grammar. You could say ':-'(p,q) 

rok> The new rule seems very confusing to me.  Pointless too.

You could get used to it if you tried hard :-)

rok> So, three formerly identical versions of a clause
rok> 	p :- q.
rok> 	(p :- q).
rok> 	:-(p, q).
rok> all mean something different in BSI Prolog.

No, the latter two are illegal!

rok> The grimoire makes it plain that
rok> 	A , B
rok> and	A & B		<--- BIG MISTAKE
rok> are both mapped to sys(and,[A,B]), but whether either of these is the
rok> same as ','(A,B) or '&'(A,B) is not said.  

The only context in which they are the same is when they are passed to
'call' or another meta-primitive which maps terms to predicates.


rok> If we take the "Abstract"
rok> lines seriously, it would appear that ','(A,B) and '&'(A,B) are
rok> distinct terms, neither of which is the same as (A,B) or (A&B).


rok> Oddly enough, if one takes the grimoire literally, the user CAN
rok> declare ',' and '&' as operators, and can use them in that form.

The syntax (not surprisingly) does not specify the semantics of the 'op'
predicate. So don't assume you can by looking there...

rok> and	A & B	<--- BIG MISTAKE
...
rok> and	A | B	<--- DEC-10 Prolog mistake retained in BSI Prolog

A DEC-10 mistake perpetuated, of course, by Quintus, Richard's company. He
obviously hasn't found it an issue worth resigning over :-)

Seriously, I'd be glad of feedback on this issue. 
Do people want: (1) just , and ; (2) allow the rather anachronistic | as well
as ; or (3) the full freedom to use logical symbols or natural language
symbols as they think fit?

rok> {Note that ;(a,b), legal in Edinburgh Prolog, is NOT legal in BSI Prolog.}
...
rok> Oddly enough, if one takes the grimoire literally, the user CAN
rok> declare ';' and '|' as operators, and can use them in that form.

In the standard everything that applies to ',' applies to ';' (unlike
Edinburgh which has different rules fo each)

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

To reiterate, [b] and [c] (as with the other operators) are illegal, but 
	('->'(p, q) ; r)
would have the interpretation you want.

rok> A similar intention may exist in rules 2.2 (:-), 2.3 (?-), 2.4 (:-),
rok> and 2.5 (-->) where the quoted items are also legal atoms.  But
rok> that's *not* what the grimoire actually says!

The S-expression syntax has exceptions in all these cases, it should have
been in the E-syntax too (in L7). None of these symbols should be atoms.

rok> There's something strange about the treatment of "{" and "}" in BSI
rok> Prolog.  According to the grimoire (rule 5.6),
rok> 	{ X }	means	pred('{}',[X])

a typo -- it should have been func -- already corrected.


rok> I'm quite sure that the fact that rules L7, L29, L30, and L15
rok> imply that <)> is a valid token is a mistake, but I just thought
rok> I'd mention it.  

in rule L15, ")" was mistyped as "(". Corrected (in the obvious way).

rok> Another probable glitch is the fact that the
rok> only way to get a backslash character in a quoted atom is to
rok> write its octal code.  (According to rule L12, \\ is NOT a legal
rok> escape sequence.)  

That's been there for a year!! How come no-one pointed it out??
Thanks, accepted.

rok> A complaint here:  if character escaping is
rok> supposed to be C-like, is it too much to ask that it should *BE*
rok> C-like?  The ANSI C escape sequences
rok> 	\a	(audible alarm)
rok> 	\v	(vertical tab)
rok> 	\\
rok> 	\?
rok> are completely missing.

I don't have a copy of ANSI C. Will be considered.

rok> The following clauses, valid in Edinburgh Prolog, are illegal in BSI Prolog.
rok> 
rok> 	/** By L22, this is not a legal comment **/

Thankyou Richard. L22 should of course read something like:

comment chars = character - "*", comment chars	| "*", end comment;
end comment = "/" | "*", end comment | character - ("*"|"/"), comment chars;

For those who are unfamiliar with this version of BNF, it has itself been
defined by a British Standard! (BS6154). "-" is for exceptions, of course.

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

Yes, thank goodness this is illegal. If you want to write it, try:

		( X @> Y -> R = (>)
etc.

rok>	not Goal :-		% "not" is not a built-in operator
rok>	    (	ground(Goal) -> \+ Goal		% neither is "\+".
rok>	    ;	signal_error(instantiation_fault(Goal,0))
rok>	    ).

This is NOT illegal if you define 'not' as an operator.

rok>[The fact that the grammar proper has no negation proper is no accident.
rok> The grammar in the grimoire defines only operators with at the level of
rok> comma and weaker.  Negation binds more tightly than comma, so it would
rok> have to be in the table of built-in operators.  The absence of any
rok> negation operator from that table may be a mistake, or it may not.  It
rok> may be the intention that one has to write \+(Goal).
rok>]

If you remember, Richard, "not" WAS defined as an operator in a previous
version of the syntax. However various members of the logic programming
community (including you if I am not mistaken) have objected strenuously
to the use of such a logical name for something which (implemented in
the usual dirty fashion by means of cut) clearly is NOT logical. Thus the
current BIP proposal contains only a predicate called "fail_if" which is
at least honest if not elegant.

rok>If we take the lexical rules (specifically L0,L1,L2) and rule 0 of
rok>the grimoire literally, any program containing a comment is illegal.
rok>The lexical rules very clearly classify comments as tokens, and as
rok>clearly return ALL the tokens, and rule 0 takes ALL the tokens and
rok>feeds them to the grimoire rules.  There is nothing in the grimoire
rok>which says that comments are dropped!

Not true; the version you have does not explicitly make any correspondence
between tokens and programs (there's no abstract part in the lexical
section). It was agreed last Wednesday that it should and this is in the
course of being added to make this very point explicit.

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

I have no intention of creating a new language. If you've ever worked on a
standards committee you would know it is impossible to get it done in a
year (let's watch the LISP folks prove me wrong :-). 
It's now got as far as being accepted by the proper number of ISO
countries with the first ISO meeting at the end of the month.
Lots of people have wanted their own pet ideas in the standard and
doubtless it won't please everybody. But it would be nice to get it
finished.

Thanks for your comments, Richard. I look forward to your replies.
Chris Moss.