Path: utzoo!mnetor!uunet!mcvax!ukc!eagle!icdoc!ivax!cdsm From: cdsm@ivax.doc.ic.ac.uk (Chris Moss) Newsgroups: comp.lang.prolog Subject: Re: BSI Proposal Message-ID: <239@gould.doc.ic.ac.uk> Date: 23 Mar 88 15:35:20 GMT References: <229@gould.doc.ic.ac.uk> <771@cresswell.quintus.UUCP> Sender: news@doc.ic.ac.uk Reply-To: cdsm@doc.ic.ac.uk (Chris Moss) Organization: Dept. of Computing, Imperial College, London, UK. Lines: 161 In article <771@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: cdsm> WRONG. The second is not allowed in the BSI form. You missed the 'h' rok> rok> I jumped to the conclusion that rule 5.5 rok>should have had 'h' as its left-hand constraint because fairly serious rok>nonsense would result if 5.5 wasn't fixed somehow. almost right; that clause didn't do what it was intended to do and I've entirely rephrased in draft 5 (in the post to you). I feel I should confess to the large number of typos and errors in the version you received. My only excuse is that most of the work was done while I was recovering from a car accident and experiencing quite a lot of back pain. It's not a good excuse, but it's the only one I have! For the same reason I didn't run that version through Prolog, tho others had applied the treatment to earlier versions. rok>Well, it depends what you mean by a symbol. I regard "fred(" or ":-(" rok>as a single token. It seems just as reasonable to do that as to regard rok>"1.0e-4" as a single token, or do you want to allow spaces there too? An intriguing viewpoint. Unfortunately not backed by the published grammar for Quintus (manual version 10, release 2.0). May I quote: term(0) --> functor ( arguments ) {provided there is no space between functor and the '('} functor --> name etc. Nowhere in the definition of "name" does "(" appear. I suggest you get Quintus to modify their grammar to fit in with your views. Incidentally, the section on "Syntax of Tokens as character strings" in the Quintus manual is even more imprecise. The only mention of '(' is in the production: punctuation-char --> () | [] | {} | , | | which, if I can possibly understand it (the use of bold characters in the manual is rather inconsistent), means that brackets can only be used in a Prolog program if paired with no characters inbetween! rok>Putting a space after a left parenthesis or before a right parenthesis rok>is appallingly bad English punctuation, so it sounds as though you must rok>have a lot of trouble with your typists working on English too. touche! rok>Do you regard the fact that a typist is likely to mistake an iota for rok>an i or an epsilon for an e as an argument that mathematiciains should rok>not use Greek letters? Should we outlaw vertical bars because bad rok>typists think they are solidii or ells or capital Is? I think you're getting away from the point -- tho in the standard we DO allow other Europeans to use their alphabetic characters with diacritical marks. rok> Surely it is inconsistent to argue that rok> "RED O" and "REDO" rok>are different, and that is a Good Thing, but rok> "red (O)" and "red(O)" rok>being different is a Bad Thing? Blanks are being treated as rok>significant in both cases. Oh dear, you don't really mean this do you Richard? rok>The only constraint is that if is a prefix operator, there must rok>be no space between and "(". Therefore :-(p,q) ***IS*** in the rok>grammar. agreed. In version 5 we have reluctantly invented the new category of "reserved graphic symbol" which includes all the system operators and not just ".". One can still get at the atomic symbols by quoting. 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. cdsm> cdsm> The only context in which they are the same is when they are passed to cdsm> 'call' or another meta-primitive which maps terms to predicates. rok> rok>No, the grimoire says very very clearly that both (a,b) and (a&b) rok>are mapped to the same Abstract, namely rok> rok> sys(and, [func(a,[]), func(b,[])]) rok> I'll say it once, then not again. Richard I CAN'T STAND your upper class British accent! If I were you I wouldn't advertise it! :-) You've made the point in another message I haven't had time to reply to yet. The grammar as you have it ONLY describes clauses. In version 5 we've provided both -- syntax for clause and for read and semantics for both states -- actually I think the double semantics is probably an overkill. The only things it really elucidates are the treatment of constructs such as if-then-else. So maybe in a future version it'll get toned down. rok>But the question of which symbols the programmer can declare as operators rok>is surely a syntactic question. If I want to know what operators I can rok>declare in Algol 68, I look in the grammar. Agreed, and it is possible in the revision. Incidentally once upon a time I liked Algol 68 too! My Ph.D. thesis contains a restatement of syntax and semantics of a largish subset of the language in DCG form. cdsm> Do people want: (3) the full freedom to use logical symbols or cdsm> natural language symbols as they think fit? rok> rok>Everyone will go for (3), of course. But that is something of a red rok>herring, as BSI Prolog won't allow it. Sure I'd like to be able to rok>write rok> every group is a monoid. rok>Oh, "natural language symbols" didn't mean that? Silly me. I think what I meant was obvious from context. One of the delights of conversing in English not Prolog! rok>This applies to the rules proper only. It does not apply to the lines rok>labelled "Constraint", "Abstract", "Priority", "Input", "Output". rok>There are at least two problems with these additional lines. rok> rok>The first, of course, is that they use a two-dimensional format where rok>the number of spaces is vitally significant: Actually, it very rarely uses spaces - usually tabs! :-) rok>One also has to watch out for the fact that some lines are omitted from rok>some rules. I believe it to be the case that to determine which attributes rok>are relevant to what non-terminals it is necessary to examine the entire rok>grammar. I took your suggestion of converting it directly to DCG form, and I hope it is true now that no attributes are omitted. It should NOT be necessary. rok>But the second, and biggest problem, is that not only are these new lines rok>not part of BS6154, the whole thing is a new formalism which is not rok>described in any of the documents that the BSI committee have sent me. It IS described in the document itself. Admittedly only in English! rok>What does it mean when a rule of the grimoire says rok> rok>Rule foo = baz, [ ugh ] ; rok>Abstract f(X,Y) X Y rok> rok>I *think* it means rok> rok> foo = baz, ugh ; rok> f(X,Y) X Y rok>+ rok> foo = baz ; rok> f(X,[]) rok> rok>but I can find nothing that says so. Correct; this IS in the current draft, together with the rest. So much for now. Chris Moss.