Path: utzoo!mnetor!uunet!mcvax!ukc!eagle!icdoc!doc.ic.ac.uk!cdsm From: cdsm@doc.ic.ac.uk (Chris Moss) Newsgroups: comp.lang.prolog Subject: re: BSI Proposal Message-ID: <229@gould.doc.ic.ac.uk> Date: 8 Mar 88 16:29:08 GMT Sender: news@doc.ic.ac.uk Reply-To: cdsm@doc.ic.ac.uk (Chris Moss) Organization: Dept. of Computing, Imperial College, London, UK. Lines: 250 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.