Path: utzoo!attcan!uunet!munnari.oz.au!mudla!ok From: ok@mudla.cs.mu.OZ.AU (Richard O'Keefe) Newsgroups: comp.lang.prolog Subject: Re: More fun with WG17 Message-ID: <2780@munnari.oz.au> Date: 22 Nov 89 08:01:04 GMT References: <2609@munnari.oz.au> <696@sce.carleton.ca> <2643@munnari.oz.au> <715@sce.carleton.ca> Sender: news@cs.mu.oz.au Lines: 154 In article <715@sce.carleton.ca>, karam@sce.carleton.ca (Gerald Karam) writes: > In article <1794@syma.sussex.ac.uk> aarons@syma.sussex.ac.uk (Aaron Sloman) writes: > plainly put, the end result will not be a radical departure, the current > versions of the draft are very much *current versions* that are being > shaped into what should be a reasonably agreeable result. if it isn't > no one will support it. I think this paragraph says "current drafts are just current drafts". Remember that the standard is already four years over-due (it was promised for the end of 1985). If the standard slips another four years, it will be obsolete when it is issued. > it might suprise you to know that most of the major vendors are represented > on the committee (BIM, SICSTUS, QUINTUS, IF, IBM and others that don't > readily come to mind, but don't be insulted :-). Quintus only came in when ANSI joined the fray. While I was there, they were not involved at all. They have had NO input into any of the drafts I have criticised. Please note: that is Quintus, not "QUINTUS". There is no organisation called SICSTUS. I am intrigued to hear that SICS are represented on the committee. I refrain from comment on BIM or IF for obvious reasons. IBM does sell a Prolog-like language, but do bear in mind that it is not compatible with any other Prolog dialect at all (it is similar in some respects to old Waterloo Prolog, but not compatible with it). It is clearly not in IBM's immediate interest to encourage the development of a standard which their product does not resemble. > it will be really > suprising if the final standard isn't exactly what these people want. > of course what vendors want is not necessarily what users want. but > that's another issue. It will be altogether extraordinary if the final standard is exactly what ANY of the vendors want. The result will be a compromise, just as the SQL, C, Fortran, and so on standards are compromises. The ONLY issue which matters is whether the standard will be good for users. Vendors (at least, some of the companies in rich Northern Hemisphere countries) can afford to buy power on the committees. But users in general can't. At the moment there isn't the slightest point in speculating about the final standard. We don't know anything about the final standard. All we can judge is the present draft. The present draft is such that I can be absolutely sure that BIM, SICS, and IF had no serious involvement in it, because it is just plain incompetent. (I can be sure that IBM had no part in it because the file system interface is quite unsuited to IBM mainframe operating systems). I mean, even if they can't run their specification you'd think they'd put it through a type-checker... > it is inevitable that some code will be broken just in trying to > resolve differences between similar, but nonetheless not identical vendor's > products. what do you expect? But WG17 broke things that _WEREN'T_ different. The previous draft demanded that atom(X) should abort with an error when X was a variable, yet none of the vendors Karam mentions did that. WG17 have thought better of that, and unbroke atom/1. But they've broken @< /2 and its friends (even deleting compare/3, which IF Prolog includes -- according to a Prentice-Hall textbook I have). findall/3 was well-established, why did they rename it to bag/3? consult/1 never used to insist on having an open stream as its argument. Yes, it is inevitable that some code will be broken, largely, I'm afraid, because very few Prolog vendors made a serious attempt to be compatible with anyone else. (The Sussex team did a very good job in Poplog, SICStus Prolog is dazzlingly good, ALS Prolog isn't bad at all, Arity/Prolog was really very compatible before they changed their operator priorities to look more like C, and even LPA Prolog, which is built on a base which is very different from DEC-10 or SICStus Prolog, is far closer to SICStus than WG17 is to either.) The point is, it's not enough to say "no omelettes without broken eggs". It is the committee's duty to know _which_ things they are breaking (they can't know about every Prolog, but they should know about the main ones), and to ensure that they provide the tools with which to repair the breaks, if possible. Let me give you an example. DEC-10 Prolog uses "..." notation for a list of character codes. So do a lot of Prologs. This is a very useful thing to have: if you care about efficient text processing and are not limited by a 64k heap segment, you will use lists of character codes rather than strings because lists of character codes let you write more efficient code than strings do. (This is true both in theory--lists are asymptotically faster than strings for most tasks--and in practice--lists are faster for even quite small problems.) Arity did a very wise thing when they added strings to their dialect: they decided not to break existing code but to introduce a third quoting character. So in Arity Prolog, 'fred' is an atom, "fred" is a list of character codes, and $fred$ is a string. This was a brilliant idea, and in my view, it is what the standard should require. BUT there are other Prolog systems (forget Turbo Prolog, I have suggested to WG17 that Turbo Prolog should be handled by writing a Turbo Prolog to Common Prolog translator) such as ESI Prolog 2 which use double-quote for strings. And there are other Prologs which have a character type (perhaps because they are built on Common Lisp, or for some other reason). What is a standards body to do? Do they rule that the DEC-10 tradition (as enhanced by Arity) be maintained (thus breaking the inferior Prologs) or do they rule that double quotes mean strings (thus breaking the Prologs whose implementors tried to be compatible)? A standards committee which saw the users' interests as paramount would break NEITHER. It would introduce a table-driven tokeniser (as in PopLog). Let's suppose that the initial syntax was -- ' is atom quote -- " is list quote -- $ is string quote -- r is radix character -- no character quote where a syntax property ranges over -1..max char, -1 meaning that no character is assigned to that property. Then :- set_syntax(string, -1), set_syntax(radix, 0r'). would go at the beginning of a file to make the tokeniser DEC-10-ish, while :- set_syntax(list, -1), set_syntax(radix, -1), set_syntax(string, 0r"). would go at the beginning of a file to make it more ESI Prolog 2-ish. I proposed using a table-driven tokeniser in 1984. The BSI committee appear to have ignored this, being more interested in inventing their own new syntax than in accomodating existing syntax, and this despite the fact that a table-driven tokeniser helps with the problem of internationalisation. I have a table-driven tokeniser which is capable of accomodating the differences between most of the Prolog dialects I have encountered. Give me up to date manuals for BIM, IF, and ZYX (it has already been influenced by out-of-date manuals for those dialects) and I'll upgrade it to handle them. That tokeniser is ~240 lines of C and is reasonably fast. I wrote the first version of it at Edinburgh. I am ready to donate it to WG17 whenever WG17 get the idea that it might be a good idea to let people read their existing files. I have already donated it to SB Prolog. Before I am accused of trying to overload the standard with features, I would like to point out that 1200 bytes of code for a tokeniser and 300 bytes of table is not a great deal; the space limit on most PC Prologs is the run-time stacks, not the compiled code for the system. This, then, is a case where the diversity of existing Prologs can be handled by *increasing* the power of the language, but where the cost to vendors of adopting the enhancement would mainly be in documentation, because they could pick up code which has been in daily use since 1984. (That's why I made read/1, write/1, setof/3 and so on public in 1984.) n > p.p.s. anyone can contribute to WG17 just send in your opinion! *DO* read the draft (N40) first, though! Two things that have been puzzling me: last year there was supposed to be a beta release of the validation suite for BSI Prolog available. What happened to it, and how did they manage to produce a validation suite for a standard that was only about 30% begun? there was an English company which I shan't name that used to advertise their product as conforming to the BSI standard. Do they still do that, and did they _know_ something or was it chutzpah?