Path: utzoo!mnetor!uunet!husc6!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.prolog
Subject: Re: BSI Proposal
Message-ID: <771@cresswell.quintus.UUCP>
Date: 14 Mar 88 07:40:24 GMT
References: <229@gould.doc.ic.ac.uk>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 408

In article <229@gould.doc.ic.ac.uk>, cdsm@doc.ic.ac.uk (Chris Moss) writes:
> 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'

Well, yes and no.  The grimoire doesn't explain what the Constraint
line means, and I had to guess.  The "February 88" draft has three
rules (5.4, 5.4 (sic), and 5.5) for parentheses, and the "Feb 88" one
has only one (5.5).  If I had taken rule 5.5 in the "Feb 88" draft
seriously, I would have been forced to the conclusion that (0) was not
a legal term in BSI Prolog!  I jumped to the conclusion that rule 5.5
should have had 'h' as its left-hand constraint because fairly serious
nonsense would result if 5.5 wasn't fixed somehow.

> 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

Well, it depends what you mean by a symbol.  I regard "fred(" or ":-("
as a single token.  It seems just as reasonable to do that as to regard
"1.0e-4" as a single token, or do you want to allow spaces there too?

> 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!)

I know, I've had that kind of trouble with typists too.  I had a perfectly
straightforward piece of ordinary mathematical text which I had to send
back three times once, and finally had to type it myself.

Putting a space after a left parenthesis or before a right parenthesis
is appallingly bad English punctuation, so it sounds as though you must
have a lot of trouble with your typists working on English too.

None of the mathematical or logical texts on my bookshelves puts a space
between a function symbol or predicate symbol and its left parenthesis,
EXCEPT when the function or predicate symbol is UNARY.  When you are
using "Curried" functions, they are of course unary, so if you have
defined
	f = lambda x. lambda y. lambda z. h(x,g(y),z)
it is entirely appropriate to write
	f 1
and 	f 2 3
but if you have defined
	f = lambda(x,y,z). h(x,g(y),z)
it is good style to write
	f(1,2,3)
rather than
	f (1,2,3)

Many logicians and mathematicians habitually use Greek letters,
subscripts and superscripts, and do exotic things like using (( as
an infix relational operator.

>       WHY THE HELL SHOULDN'T THEY??

You tell me.

Do you regard the fact that a typist is likely to mistake an iota for
an i or an epsilon for an e as an argument that mathematiciains should
not use Greek letters?  Should we outlaw vertical bars because bad
typists think they are solidii or ells or capital Is?  And while we're
at it, a lot of people like using hyphens and don't understand or
don't like the break character, so shouldn't we throw out "_" and
allow instead identifiers like this-is-one-token.  After all, typists
often mistake "_" for "-".

As Chris Moss says, most languages since Fortran regard blanks as
significant.  Surely it is inconsistent to argue that
	"RED O" and "REDO"
are different, and that is a Good Thing, but
	"red (O)" and "red(O)"
being different is a Bad Thing?  Blanks are being treated as
significant in both cases.  "RED O" and "red (" are both two tokens,
and "REDO" and "red(" are both one token; it's exactly the same thing.
What's sauce for the goose is sauce for the gander.

As it happens, I'm an Algol 68 fan.  I like having spaces inside
identifiers, rather than underscores or hyphens.  I even have a version
of the public-domain parser which lets me treat

	list length([], 0).
	list length([_|Tail], succ(N)) :-
		list length(Tail, N).

as Prolog.  ("list length" turns into "list_length".)  Does this mean I
think the standard should allow spaces inside identifiers?  No way!
I think this is 10% better than what we have now, which is good enough
to put it in some other language, but it's nowhere _near_ enough of an
improvement to change the language we already have.

> 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) 

By lexical rule L29, ":" and "-" are graphic characters.
By lexical rule L7, ":-" is a graphic symbol.
By lexical rule L3, ":-" is thus an atom.

By syntax rule 5.4, <atom> "(" <termlist> ")" is a term/h.
The only constraint is that if <atom> is a prefix operator, there must
be no space between <atom> and "(".  Therefore :-(p,q) ***IS*** in the
grammar.

> 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.

No, the grimoire says very very clearly that both (a,b) and (a&b)
are mapped to the same Abstract, namely

	sys(and, [func(a,[]), func(b,[])])

***LEXICAL*** rule L19 says
	and symbol = "&" | "," ;
so when we get to syntax rule

4.1		goals		= term, [and symbol, goals] ;
Constraint	X		  X		     X
Abstract	sys(and,[A,B])    A		     B

there is no possibility of distinguishing between "," and "&": there is
*NOTHING* associated with the "and symbol" which can participate in the
Abstract.

"&" is not equivalent to "," between <function(> and <)> or between
<[> and <]>.  But functioning as an "and symbol" it is quite
indistiguishable from ",", at least according to the grimoire, and
that is all I can go on.

> 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...

Quite right.  In fact, since the grimoire says on page 5 "The following
table defines the "is_op" table used in clauses 8-10 above", it would be
closer to the truth to say that the grimoire forbids user-defined
operators entirely.  Silly me.

But the question of which symbols the programmer can declare as operators
is surely a syntactic question.  If I want to know what operators I can
declare in Algol 68, I look in the grammar.  If I want to know what
operators I can overload in ADA, I look in the grammar.  If I want to know
what operators I can declare in Pop-2, I look in the grammar, which tells me
that operators look just like other symbols.  If not in the grimoire,
where SHOULD I look to find out what operators I can declare?

> 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 :-)

I agree that it is a mistake, from the point of view of language design.
I keep asking people here at Quintus not to use it, and when I edit
any system files I surreptitiously change "|"s to ";"s.  But Quintus
don't claim to have a SUPERIOR syntax, they claim to have a COMPATIBLE
syntax, and compatible means compatible, even with features I might not
happen to like.  I think this line has been misread:  I meant the
comment to indicate that (a) I don't like it, but (b) because it is part
of the de facto standard it *should* be retained in BSI Prolog.

> Do people want: (3) the full freedom to use logical symbols or
> natural language symbols as they think fit?

Everyone will go for (3), of course.  But that is something of a red
herring, as BSI Prolog won't allow it.  Sure I'd like to be able to
write
	every group is a monoid.
Oh, "natural language symbols" didn't mean that?  Silly me.
I'd like a language in which I could use branching quantifiers and
modal operators.  Oh, "logical symbols" didn't mean that?  Silly me.

> 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.

The interpretation I *want* is the one [a] gets.
What I *fear* is that ('->'(p,q) ; r) will get the *other* one.

[b] would be illegal for the simple reason that the grimoire
does not list "->" and ";" at the foot of page 5 (the table of built in
operators) and provides no other means of making ANY atoms legal operators.
However,

By lexical rule L29, "-" and ">" are graphic characters.
By lexical rule L6, "->" is a graphic symbol.
By lexical rule L3, "->" is an atom.

By lexical rules L4 and L3, "p" and "q" are atoms.

By syntax rule 5.3, p and q are terms, and by syntax rule 6, "p, q"
is a termlist.  By syntax rule 5.4, "->(p, q)" is therefore a legal term.
Indeed, since "->" is not a prefix operator, "->  (p, q)" is also a legal
term.

So [c] is ***NOT*** illegal.  Even if operators had to be quoted,
by virtue of the fact that the control structures are hardwired into
the grammar, '->' and ';' do not appear in is_op/3, the table of built-in
operators, it follows from syntax rules 8, 9, and 10 that -> is neither
a prefix op, nor a postfix op, nor an infix op.  Even if it were an
infix op, that would not make ->(p,q) illegal, at least not in the
version of the grimoire that I was citing (the "Feb 88" one, not the
"February 88" one).

> 
> 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.

So when Chris Moss said above:
> 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) 
what he REALLY meant was "there is a mistake in the version of the
grimoire you have, you have correctly understood what it said, but
that's not what we meant."

> 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).
> 
Simply changing "(" to ")" would have the result of making <(> legal.
Presumably _both_ "(" and ")" are "solo symbol"s.

> 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:
> 
I see, you think it is nasty of me to stop people writing
	ugly
								(
	code							)
by saying that the standard should stick with what we've already got,
but it's fine for you to take away something I'm already using.  TANJ!

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

My point was not that "not" is not an operator, but that NEITHER
"not" NOR the preferred "\+" is an operator.

> 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.
> 
Not true.  I referred (as quoted!) to syntax rule 0, which is explicitly
described as "the interface between the two sections".  If this does not
"explicitly make any correspondence between tokens and programs", what
DOES it do?

> I have no intention of creating a new language.

About your intentions, I have nothing to say.  You are the only authority.
About your *actions*, I can only say that whatever you intend, BSI Prolog
is about as different from Edinburgh Prolog as Turbo Pascal is from ISO
Pascal.

> 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.

When I saw that the BSI committee had had the effrontery to propose their
stuff to ISO, I was speechless with rage.  I think the ISO approach to
internetworking is enough to show that being accepted by some number of
ISO countries is no guarantee of quality.

> 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.

This applies to the rules proper only.  It does not apply to the lines
labelled "Constraint", "Abstract", "Priority", "Input", "Output".
There are at least two problems with these additional lines.

The first, of course, is that they use a two-dimensional format where
the number of spaces is vitally significant:

	foo	= baz, ugh ;
Thingy	X	  X	

and
	foo	= baz, ugh ;
Thingy	X	       X

are *very* different.  If allowing arbitrary amounts of space inside
a <function(> token is such a wonderful thing, the grimoire should take
its own medicine.  Perhaps something like
	foo	= baz, ugh ;
Thingy	X	: X,   _   ;

and
	foo	= baz, ugh ;
Thingy	X	: _,   X   ;

One also has to watch out for the fact that some lines are omitted from
some rules.  I believe it to be the case that to determine which attributes
are relevant to what non-terminals it is necessary to examine the entire
grammar.  

But the second, and biggest problem, is that not only are these new lines
not part of BS6154, the whole thing is a new formalism which is not
described in any of the documents that the BSI committee have sent me.
What does it mean when a rule of the grimoire says

Rule	 foo = 	baz,  [ ugh ] ;
Abstract f(X,Y)	X	Y

I *think* it means

	 foo =	baz, ugh ;
	 f(X,Y)  X    Y
+
	 foo =   baz ;
	 f(X,[])

but I can find nothing that says so.  What does it mean when a rule of
the grimoire uses

Rule	 		.... { stuff } ....
Abstract			X
Other				k

I *think* it means

Rule			.... stuff-star ....
Abstract			X
Other				k
where

Rule	 stuff-star = empty ;
Abstract []
Other	 K	
+
Rule	 stuff-star = stuff, stuff-star ;
Abstract [X|Xs]		X	Xs
Other	 K		K	K

but I can find nothing that says so, neither is it said anywhere which
attributes participate in listification and which do not.  Now the one
thing a standard _must_ not do is leave you guessing!

> Lots of people have wanted their own pet ideas in the standard ...

I don't want *ANY* of *my* pet ideas in the standard.
Look, if you took Fernando's version of C Prolog (not mine)
and stamped "BSI" on it, I wouldn't mind much.
Dash it, you could take *ALS* Prolog and stamp "BSI" on it, and
I'd think more highly of the BSI committee.
All I want is a standard which is close to existing practice and
spells things out in rather more detail than most manuals.

I want everyone reading this to understand my position clearly:
    (1) what would be a good syntax for a logic programming language?
    (2) what should the standard syntax be?
I regard these as two very different questions.  I think Pascal syntax
is little short of insane, but that doesn't mean that I think the Pascal
_standard_ should have departed from it.  I think C syntax is bizarre,
but that doesn't mean that I think X3J11 should redesign it.  When I
write down logical clauses, I use '<-" for if, '&' for and, '|' for
or, and am as likely to use ';' at the end as '.'.  So what?  That's
not the way Edinburgh Prolog ***IS***.

A committee such as the BSI Prolog one is not the best way to answer
question (1).  The right thing to do is to perform experiments.


Richard (there is little so bad that changing it won't make it worse) O'Keefe