Path: utzoo!mnetor!uunet!lll-winken!lll-tis!mordor!sri-spam!sri-unix!quintus!ok From: ok@quintus.UUCP (Richard A. O'Keefe) Newsgroups: comp.lang.prolog Subject: Re: BSI syntax Message-ID: <737@cresswell.quintus.UUCP> Date: 6 Mar 88 08:51:03 GMT References: <736@cresswell.quintus.UUCP> Organization: Quintus Computer Systems, Mountain View, CA Lines: 289 Summary: an example 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?