Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!ok From: ok@quintus.UUCP (Richard A. O'Keefe) Newsgroups: comp.lang.prolog Subject: Re: BSI Proposal Message-ID: <816@cresswell.quintus.UUCP> Date: 25 Mar 88 04:33:20 GMT References: <229@gould.doc.ic.ac.uk> <771@cresswell.quintus.UUCP> <239@gould.doc.ic.ac.uk> Organization: Quintus Computer Systems, Mountain View, CA Lines: 98 In article <239@gould.doc.ic.ac.uk>, cdsm@ivax.doc.ic.ac.uk (Chris Moss) writes: > 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. I'm sorry to hear this, and hope that you are recovered. Would it be appropriate to mark some of the documents "not for review"? It didn't seem to me that the "Feb 88" document had significantly more problems than the "February 88" one. > 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: I said that __I__ regard "fred(" as a single token. I did *not* say that __Quintus__ share this point of view. I have been pushing this view since 1983. Presumably everyone reading this newsgroup has read the document "How to Use Usenet" (there is a package of such documents broadcast in news. every couple of months; your news administrator should be able to provide you with a copy, it's also part of the documentation set which comes with the B news sources). Every message in this or any other newsgroup comes with an implicit disclaimer: the views of the poster are not to be taken as the views of his organisation. My views are not necessarily the views of Quintus. What Quintus see fit to put in a manual is not necessarily something I like, agree with, or even know about. Nor do I have the power to make Quintus put anything I might happen to want or like into the language or the manuals. > 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. What other Europenas may use was not the point. The original claim was that because typists sometimes mistake "fred(" for "fred (" the blank should be allowed, and I was rebutting that by pointing out that we do not allow such mistakes to forbid other useful typographical practices. In fact it *has* been proposed in all seriousness (CACM, early 70s) that programming languages should treat 0 and O in identifiers as identical. > 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? Yes I do. Whyever not? Where does the analogy break down? The BSI grimoire treats "f-1" and "f -1" differently, after all. > 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! :-) Pardon? I haven't got any sort of British accent. No Aotearoa ahau! And I don't see the relevance of my accent to a discussion of Prolog syntax. > 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. Look, for the purpose of explaining how things like read(X), call(X) work, the BSI standard must include in some fashion a mapping from terms-qua-terms to terms-qua-code. Why not simply specify the grammar of terms-qua-terms, and define the meaning of terms-qua-code as the image of the term reading under the term-to-code map? > 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! No, the document I have seen merely says (incompletely) what the formalism LOOKS like. There was nothing to say what it MEANS, not in any language. What the document said was "Each entry should be considered as a parameter of a logic grammar (i.e. a definite clause or metamorphosis grammar)." It didn't say how the correspondence is to be realised, which means that the treatment of [optional] and {repeated} items was left completely unclear. Neither is it explained what -exceptions with "facets" mean, but that's ok because only the lexical rules use -exceptions and they haven't any facets.