cdsm@sappho.doc.ic.ac.uk (Chris Moss) (11/10/89)
In article <2643@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes: >The internal politics of WG17 are quite irrelevant. >The point is, *I* don't get a vote. Lee Naish doesn't get a vote. Rick >Muggridge doesn't get a vote. The team at HP don't get a vote. >Virtually *all* of the people who are using Common Prolog systems (that >is, virtually all of the people who will be affected by WG17) have no >representation at all. Hold on Richard, many of the people you're talking to don't know the history of this. 1. ISO committees are formed by their representative organisations in the countries that form it. When a working group is set up all countries get the option of (a) participating (b) supporting but not participating (c) opposing the working group. When WG17 was set up, Britain, France, Germany etc. chose (a), the US chose (b) and very few countries chose (c). This seems to me a totally democratic procedure. Most countries prefer representative not participatory democracy, and that's what's happening in this case. I've argued for several years that if Americans want to influence the committee they should force ANSI to participate. Unfortunately the Americans, having been the most powerful economic force for the last 40 years, are generally offhand about democracy when it doesn't suit them. (And they are of course more interested in a Lisp standard.) > but many nations are not represented at all (there is >no New Zealand representation, for example), but it isn't REALLY "the >Swiss" or "the French" but the particular people who managed to get >themselves appointed as national representatives. yes, and the paths to that ARE open. >Let's be honest about this: democracy is rule BY the same people >who are affected. No, that is participatory democracy. When countries (such as Nicaragua) try to set up systems which include this, the Americans institute economic boycotts, support terrorists and the like. (I'm not saying you support them Richard.) >Some of us (like me) can't vote for a representative >even in principle. For those who don't know, Richard was in Scotland when the idea of a committee was first mooted. He contributed a number of valuable documents, but was in California and therefore not able to participate in British meetings when things were really moving. (No, email has not been a satisfactory substitute!) Now he is back in New Zealand. NZ is a member of ISO, but is NOT a member of JTC1 or SC22 and therefore does not vote on this. However they are able to send representatives, as far as I know. Standardisation inevitably involves travel and expense, so countries won't participate unless they feel it is in their economic interest to do so. In turn it is generally the companies which foot the bill. Have you approached the NZ standardization body, Richard? If so, what was their response? > Those of us who belong to countries which are >"represented" did not get any opportunity to pick their "representatives". This depends entirely on the country. In Britain, which was where the Prolog standardization started, meetings are open to all who wish to attend. Indeed many feel this is part of the problem. Rather than have delegates who speak for proper causes (manufacturers, universities, users etc.) decisions are taken by whoever comes along. Hence the frequent reversals of policy. Other countries have different policies. That seems acceptable to me. Top-down rule setting isn't necessarily the way to get the right result. As far as WG17 is concerned, individuals can attend meetings, though at the end of the day it is countries that vote. Anyone who wants to go, write to Roger Scowen, NPL, Teddington, Middx, UK for an invitation! >Insofar as its relations to the people it seeks to govern are concerned, >WG17 is NOT democratic, and if the members of WG17 were concerned to >protect the interests of people using Common Prolog it wouldn't need to be. Ah, this mention of Common Prolog again. Is this really what you want, Richard? While we don't have a Guy Steele to write the book, it seems to me that the "throw in every way of doing it" philosophy is something you have argued against at other times. I'll have to give it a break there. I don't write as fast as Richard! Chris Moss.
cdsm@doc.ic.ac.uk (Chris Moss) (11/10/89)
In article <2643@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes: >The internal politics of WG17 are quite irrelevant. >The point is, *I* don't get a vote. Lee Naish doesn't get a vote. Rick >Muggridge doesn't get a vote. The team at HP don't get a vote. >Virtually *all* of the people who are using Common Prolog systems (that >is, virtually all of the people who will be affected by WG17) have no >representation at all. Hold on Richard, many of the people you're talking to don't know the history of this. ISO committees are formed by their representative organisations in the countries that form it. When a working group is set up all countries get the option of (a) participating (b) supporting but not participating (c) opposing the working group. When WG17 was set up, Britain, France, Germany etc. chose (a), the US chose (b) and very few countries chose (c). This seems to me a totally democratic procedure. Most countries prefer representative not participatory democracy, and that's what's happening in this case. I've argued for several years that if Americans want to influence the committee they should force ANSI to participate. Unfortunately the Americans, having been the most powerful economic force for the last 40 years, are generally offhand about democracy when it doesn't suit them. (And they are of course more interested in a Lisp standard.) > but many nations are not represented at all (there is >no New Zealand representation, for example), but it isn't REALLY "the >Swiss" or "the French" but the particular people who managed to get >themselves appointed as national representatives. yes, and the paths to that ARE open. (see below about NZ) >Let's be honest about this: democracy is rule BY the same people >who are affected. No, that is participatory democracy. When countries (such as Nicaragua) try to set up systems which include this, the Americans institute economic boycotts, support terrorists and the like. (I'm not saying you support them Richard.) >Some of us (like me) can't vote for a representative >even in principle. For those who don't know, Richard was in Scotland when the idea of a committee was first mooted. He contributed a number of valuable documents, but was in California and therefore not able to participate in British meetings when things were really moving. (No, email has not been a satisfactory substitute!) Now he is back in New Zealand. NZ is a member of ISO, but is NOT a member of JTC1 or SC22 and therefore does not vote on this. However they are able to send representatives, as far as I know. Standardisation inevitably involves travel and expense, so countries won't participate unless they feel it is in their economic interest to do so. In turn it is generally the companies which foot the bill. Have you approached the NZ standardization body, Richard? If so, what was their response? > Those of us who belong to countries which are >"represented" did not get any opportunity to pick their "representatives". This depends entirely on the country. In Britain, which was where the Prolog standardization started, meetings are open to all who wish to attend. Indeed many feel this is part of the problem. Rather than have delegates who speak for proper causes (manufacturers, universities, users etc.) decisions are taken by whoever comes along. Hence the frequent reversals of policy. Other countries have different policies. That seems acceptable to me. Top-down rule setting isn't necessarily the way to get the right result. As far as WG17 is concerned, individuals can attend meetings, though at the end of the day it is countries that vote. Anyone who wants to go, write to Roger Scowen, NPL, Teddington, Middx, UK for an invitation! >Insofar as its relations to the people it seeks to govern are concerned, >WG17 is NOT democratic, and if the members of WG17 were concerned to >protect the interests of people using Common Prolog it wouldn't need to be. Ah, this mention of Common Prolog again. Is this really what you want, Richard? While we don't have a Guy Steele to write the book, it seems to me that the "throw in every way of doing it" philosophy is something you have argued against at other times. I'll have to give it a break there. I don't write as fast as Richard! Chris Moss.
ok@cs.mu.oz.au (Richard O'Keefe) (11/13/89)
In article <1354@gould.doc.ic.ac.uk>, cdsm@doc.ic.ac.uk (Chris Moss) writes: > ISO committees are formed by their representative organisations in > the countries that form it. When a working group is set up all countries > get the option of (a) participating (b) supporting but not participating > (c) opposing the working group. When WG17 was set up, Britain, France, > Germany etc. chose (a), the US chose (b) and very few countries chose (c). > > This seems to me a totally democratic procedure. Most countries prefer > representative not participatory democracy, and that's what's happening > in this case. Let's back up a step in this thread: the starting point was that Andre Vellino (sorry if the spelling is wrong, I can't find the original article any more) said that one of WG17's problems was being too democratic. I said that (a) as long as the members are wise and benevolent it doesn't matter whether it's democratic or not, and (b) the internal organisation of the committee may be as democratic as you please, what really matters is the consent of the governed. I cannot agree that the setting up of WG17 was "a totally democratic process". To check my understanding of this, I actually went out and bought a new dictionary (the Collins COBUILD, Aus$20, ISBN 0-00-370023-2). democratic 2 Something that is democratic is based on the idea that everyone should have equal rights and should be involved in making important decisions. What worries me is not voting as such but that the *people* who are going to be affected by the standard are not *represented*. Countries are legal fictions: to say that "most countries prefer representative democracy" is a sort of verbal shorthand for "in most of the countries where a form of government said by the governors to be democratic the people who are governed have never been given a choice between participatory and representative democracy, so the form practiced by the governments in question more closely resembles representative democracy." Now in what sense did "New Zealand" (for example) _choose_ not to be active in the Prolog standard? Well, Chris Moss informs us that > NZ is a member of ISO, but is NOT a member > of JTC1 or SC22 and therefore does not vote on this. This is the procedure he says is "totally democratic". I repeat, I myself don't think it's a bad thing for a standards body to be non-democratic. I *do* think that the committee ought to consider the interests of the people who are _not_ represented (which is pretty well all of us; representation of your _country_ is not representation of _you_) as paramount. > Ah, this mention of Common Prolog again. Is this really what you want, > Richard? While we don't have a Guy Steele to write the book, it seems to > me that the "throw in every way of doing it" philosophy is something > you have argued against at other times. Well, there are a lot of things to admire about Common Lisp. It was produced in a very co-operative way. A great deal of the proposed language was *implemented* BEFORE the standards committees were formed. That is exactly what I tried to do in 1984: my document about Prolog evaluable predicates and my posting of public-domain code for read/1 and friends, write/1 and friends, setof/3 and friends, and a top level, they were all an attempt to get the Prolog community interested in a co-operative development of a new compatible edition of the language. My idea was that we should take the new edition to the standards bodies *after* we had worked out some degree of consensus about what it should look like. I would like to point out that this approach HAS worked at least to this extent: SICStus Prolog and Quintus Prolog have very compatible syntax because they both started from the public-domain parser. (They also started with similar implementations of setof/3.) In much the same way, SB-Prolog 3.0 is closer to Quintus lexical syntax than older versions because it has a tokeniser I contributed. The idea of encouraging compatibility by providing free code to make it _easy_ to be compatible is an idea I got from Common Lisp: one of the things that encouraged people to stick with Common Lisp was the free compiler. (Actually, it's rather unfair to describe Common Lisp as "throw in every way of doing it". For the most part they picked one approach for each thing and stuck with it.) There is a "Common Prolog" family of Prolog systems whose designers mode serious attempt to be compatible with DEC-10 Prolog and/or C Prolog. DEC-10 Prolog, C Prolog, PopLog (when I last saw it about 5 years ago), ALS Prolog, Quintus Prolog, NU Prolog, SICStus Prolog, Edinburgh Prolog (NIP), Prolog-X, BIM Prolog in compatibility mode, ZYX "Q Prolog", Arity/Prolog, even LPA Prolog to a large extent, though it is different underneath. That cluster has a "centroid" which is a pretty reasonable language; it would be possible to standardise to that without breaking much. "Common Prolog" is the name I give to this "centroid". There are a number of things which have to be tidied up (such as floating-point arithmetic, error handling, streams), but the guiding principle is to adopt what one can from existing Common Prologs and to break only what one must. (We may not have a Guy Steele to write the book; would a Richard O'Keefe do? I'm still waiting to receive any comments at all on the documents I sent to the BSI committee; what's wrong with PS/6 and the 1984 formal definition?) But the important thing about Common Lisp is that it was already working both as implementations and as a standard BEFORE they took it to the standards bodies. It is in fact the case that you can write non-trivial programs in Common Lisp and expect them to port from a PC to a Mac to UNIX to a MacIvory to VMS. It may be big, but it _works_. I'd like to see a Prolog standard that works even half as well.
fuchs@unizh.UUCP (fuchs) (11/14/89)
> That is exactly what I tried to do in 1984: my document about Prolog > evaluable predicates and my posting of public-domain code for read/1 > and friends, write/1 and friends, setof/3 and friends, and a top level, > they were all an attempt to get the Prolog community interested in a > co-operative development of a new compatible edition of the language. Richard, where does one find your 1984 formal definition of Prolog? Would you care to put it on comp.lang.prolog? --- nef
cdsm@sappho.doc.ic.ac.uk (Chris Moss) (11/14/89)
In article <2688@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes: >I cannot agree that the setting up of WG17 was "a totally democratic >process". To check my understanding of this, I actually went out and >bought a new dictionary (the Collins COBUILD, Aus$20, ISBN 0-00-370023-2). > >democratic 2 > Something that is democratic is based on the idea that everyone > should have equal rights and should be involved in making > important decisions. Ah but you haven't quoted the first definition: democratic 1 A country, government, or political system that is democratic has representatives who are elected by the people. This is closer to what we are talking about and I have to agree WG17 is NOT totally democratic, except in a roundabout way. Our democratic (?) countries decided to participate in ISO and mandated the appropriate bodies to take the decisions for them. Indeed I criticized WG17 for being somewhat cavalier with the representative nature of the exercise. >Now in what sense did "New Zealand" (for example) _choose_ not to be >active in the Prolog standard? Well, Chris Moss informs us that >> NZ is a member of ISO, but is NOT a member >> of JTC1 or SC22 and therefore does not vote on this. >This is the procedure he says is "totally democratic". But, Richard, one of the principles dear to the hearts of Western democracies is the right of anyone NOT to participate if they don't want to. (Do we approve of compulsory voting?) NZ CHOSE not to participate. >I repeat, I myself don't think it's a bad thing for a standards body >to be non-democratic. Forget the above argument. It's obviously irrelevant! (:-) >(We may not have a Guy Steele to write the book; would a Richard O'Keefe do? As far as I'm concerned, yes. In 1984 I hoped we might get a better language than what you call "Common Prolog". Now I'm older and have fewer illusions. But I'm not sure it would solve the problems while there is an ISO committee with a different agenda. Look at LISP. Now it's gone into the standards game all the old arguments (Scheme, core versions etc.) have got their supporters. I'm not up to date on the current state of battle (Can anyone comment?) but I doubt they'll get any agreement for Common Lisp. Chris Moss.
ok@mudla.cs.mu.OZ.AU (Richard O'Keefe) (11/15/89)
In article <310@unizh.UUCP>, fuchs@unizh.UUCP (fuchs) writes: > where does one find your 1984 formal definition of Prolog? Would you care > to put it on comp.lang.prolog? --- nef Well, it was sent to the BSI committee, so it _should_ have been assigned a PS/ number and it _should_ be obtainable from them. It also saw the light of day as an Auckland University Computer Science report entitled "A Formal Specification of Prolog". I've retyped it from memory here, and it runs naive reverse at the incredible speed of 1.3 LIPS. Trouble is that the definition is written in a pure functional style and can't take advantage of Prolog. Here's what the data base for naive reverse looks like: db_example( mu(append/3, [ clause([ nonvar('[]',0,[]), % append([] var(1), % ,X var(1) ], % ,X) :- true), % true. clause([ nonvar('.',2,[ % append([ var(1), % H| var(2)]), % T] var(3), % ,L nonvar('.',2,[ % ,[ var(1), % H| var(4)]) ], % R]) :- user(append/3, [ % append( var(2), var(3), var(4)]) % T, L, R) )], mu(reverse/2, [ clause([ nonvar('[]',0,[]), % reverse([] nonvar('[]',0,[]) ], % ,[]) :- true), % true. clause([ nonvar('.',2,[ % reverse([ var(1), % H| var(2)]), % T] var(3) ], % ,R) :- ( user(reverse/2, [ % reverse( var(2), var(4) ]) % T, L) , user(append/3, [ % , append( var(4), % L nonvar('.',2,[ % ,[ var(1), % H| nonvar('[]',0,[])]), % []] var(3) ]) % ,R) ))], none)) ). I mean to post the thing to the net when I've got findall/3 defined.
ok@mudla.cs.mu.OZ.AU (Richard O'Keefe) (11/16/89)
In article <1355@gould.doc.ic.ac.uk>, cdsm@sappho.doc.ic.ac.uk (Chris Moss) writes: > >Now in what sense did "New Zealand" (for example) _choose_ not to be > >active in the Prolog standard? > But, Richard, one of the principles dear to the hearts of Western > democracies is the right of anyone NOT to participate if they don't want > to. (Do we approve of compulsory voting?) NZ CHOSE not to participate. There is no moral agent called "NZ". The only sense in which it can be said that "NZ CHOSE not to participate" is this: "a group of people who control a certain bureacracy made a general policy decision which resulted in the fact that NZ is not represented on WG17, this decision was not made with reference to WG17 as such, and the result obtained without ANY of the Prolog programmers actual or potential in NZ being consulted." Put it this way, if George Bush went raving mad and pushed The Button, we could say in precisely the same sense that "the USA CHOSE to commit suicide". This does not seem to be a useful way of using the word "chose". > In 1984 I hoped we might get a better > language than what you call "Common Prolog". Now I'm older and have > fewer illusions. I'm not sure whether Chris Moss and I understand quite the same thing by "Common Prolog". Common Prolog is actually a pretty good programming language. I think we are all agreed that "Prolog as we know it" is not an ideal logic programming language, and we're probably agreed that there _ought_ to be a better one, but it is _not_ the job of the standards committee to produce it. My position on this has always been "freeze Prolog as it stands so that people who want to _USE_ it can get on with their work without having to wait N years for a new language to be designed". As it is, in their pursuit of their individual Holy Grails, the BSI and ISO committees have failed to produce *either* a better language *or* a workable standard; even if they repent and start to do good work they must bear the responsibility for having delayed the "good-enough" standard that was feasible five years ago. > But I'm not sure it would solve the problems while there is an ISO > committee with a different agenda. Look at LISP. Now it's gone into the > standards game all the old arguments (Scheme, core versions etc.) have > got their supporters. The Scheme standard is a completely different standard altogether. The last I heard (yesterday) it was supposed to be pretty nearly finished, and not all that much different from the R3RS. Whatever happens to the Lisp standard, the people who worked on Common Lisp deserve praise for having produced something that has FUNCTIONED as a standard since CLtL came out. Before CLtL, there was no way that you could expect to move Lisp code from PC to Mac to VMS to UNIX to LispM. Now, with all its flaws, you _can_ do that. Let's face it, what more could we expect from a standard? Academics don't have to use standardised languages. If you want to write your next program in a mixture of Little SmallTalk and Perl, there is nothing to stop you. Standards are for engineers who are trying to build products or prototypes for products. They're for people who haven't got access to the sources so they can't add missing features or port the thing to a new machine themselves. A standard has to be consistent, utterly clear, and it has to describe something which is known to be workable even if it has warts. It also has to be timely: if WG17 can just hang on for another 10 years no-one will _care_ what they do.
cdsm@sappho.doc.ic.ac.uk (Chris Moss) (11/17/89)
In article <2717@munnari.oz.au> ok@mudla.cs.mu.OZ.AU (Richard O'Keefe) writes: RO>> >Now in what sense did "New Zealand" (for example) _choose_ not to be RO>> >active in the Prolog standard? CM>> NZ CHOSE not to participate. > >There is no moral agent called "NZ". Agreed >The only sense in which it can be said that "NZ CHOSE not to participate" >is this: "a group of people who control a certain bureacracy made a >general policy decision which resulted in the fact that NZ is not >represented on WG17, this decision was not made with reference to WG17 >as such, and the result obtained without ANY of the Prolog programmers >actual or potential in NZ being consulted." Put it this way, if George >Bush went raving mad and pushed The Button, we could say in precisely >the same sense that "the USA CHOSE to commit suicide". This does not >seem to be a useful way of using the word "chose". I don't agree. It depends whether you are using "raving mad" in a clinical sense or simply in the sense that most of us would describe anyone as mad who pushed the button. In this case it seems that the New Zealand representative of ISO might well have been entirely rational in deciding not to participate: the expense may not be worth the payoff. As far as the US is concerned I don't think they were rational. For that reason I was VERY glad to see Dave Bowen's note saying that ANSI was forming a Prolog standardization group. Well done, Dave! >Academics don't have to use standardised languages. If you want to write >your next program in a mixture of Little SmallTalk and Perl, there is nothing >to stop you. Standards are for engineers who are trying to build products >or prototypes for products. True. There's another problem. Academics don't get PAID to write standards, nor do they get many brownie points for it. That's why the amount of time I was able to give was strictly limited. (maybe that was a good thing!) Now I know you don't get paid to write a standard either, Richard! If you have the determination of Richard Stallman to carry on then you're a lot better man than I am (does he get a salary from MIT?) As I've said before, the difference between Prolog and (say) C is that there have been a number of attempts to get Prolog right, and the Edinburgh one was not the first. Thus the priority issue is far from clear. I didn't come from the Edinburgh camp - the first one I used was Waterloo, the second micro Prolog. Thus the portmanteau approach of Common Lisp would have been a more appropriate model than "do it the Edinburgh way". (It has its own drawbacks - I'm not suggesting I would prefer it altogether.) The same arguments came when the French joined, and so on. Ultimately it depends on who is in charge - whether they are competent and good managers. That's the core of the problem. Chris Moss.
isaac@goanna.oz.au (Isaac Balbin) (11/17/89)
All this talk of definition of democracy etc is academic --- pragmatically, the definitions are irrelevant; what is relevant in terms of definition is the motives and objectives of the committee. In this respect, there is one clear fact, any committee that does not invite the opinions of people such as Drs Richard O'Keefe, Lee Naish and the like is fundamentally flawed. Who cares about country of origin? Just make sure you get the best people.
ok@mudla.cs.mu.OZ.AU (Richard O'Keefe) (11/18/89)
In article <1359@gould.doc.ic.ac.uk>, cdsm@sappho.doc.ic.ac.uk (Chris Moss) writes: > In this case it seems that the New Zealand representative of ISO might well > have been entirely rational in deciding not to participate: the expense may not > be worth the payoff. I really must probe a little more when I get back. I have no idea what "the New Zealand representative of ISO" might be (the idea of the ISO having an ambassador somewhere in Wellington has charm, I must admit). I will be very surprised indeed if the NZSI ever made any decision about Prolog as such at all. > As I've said before, the difference between Prolog and (say) C is that there > have been a number of attempts to get Prolog right, and the Edinburgh one was > not the first. Thus the priority issue is far from clear. This isn't such a big difference from C: C itself is merely one member of a related family of notations, and Whitesmiths C was seriously different (the syntax was much the same, but the library functions were not, and that is the level that mainly matters for Prolog). "Priority" is a total red herring, here. If we went by priority, I think we'd have to go for the Begriffschrift (sp?) -- I've been surprised that no-one has revived it as a "graphical Prolog". Or GOLUX. A standard is for a PRACTICAL purpose. The criterion which guides a standard is "what will maximise the practical utility of this standard?" At the time that the BSI committee was formed, the answer was clear: the Edinburgh branch of the Prolog family stood out in terms of number of implementations that were intended to be compatible, in terms of books in print or in progress, and in terms of public-domain software coded in that dialect (the DEC-10 Prolog library). My own goal in writing the DAI report which became PS/6 was to spell out the minimal level of built-in predicates I needed in order to make the library portable, so that I could spend time extending the library rather than porting it. Let's consider availability now, and see what it tells us about whether a Prolog standard should resemble Edinburgh Prolog, or Turbo Prolog, or Prolog III, or micro-PROLOG. On this machine at the moment there are Quintus Prolog, SICStus Prolog, NU Prolog, MU Prolog, Stony Brook Prolog, and a copy of the Berkeley Prolog system which I haven't actually installed yet. Within my reach I have floppy discs for LPA Prolog Professional and LPA Mac Prolog. On the Sun I could also get by paying for them (if I had the money) IF Prolog, BIM Prolog, and ALS Prolog. IF has a Mac implementation that I know of, and ALS has a Mac and a PC implementation. I've also got a copy of C Prolog on a tape somewhere. I nearly forgot Poplog, which would be a pity. All of these are reasonable compatible with the Edinburgh family. (Oops, I forgot `Edinburgh' Prolog (was NIP).) Where are the imitators of Turbo Prolog, of Prolog III, of micro-PROLOG? (micro-PROLOG's successor is LPA Prolog, where micro-PROLOG-like syntax is an option dismissed to an appendix in the Professional manual and is absent from the Mac version. The Professional manual says "Warning: LPA does not guarantee to support the standard syntax in future versions of LPA Prolog Professional" where by "standard" they mean micro-PROLOG.) Of the systems on the Sun, SB Prolog costs nothing, the Berkeley Prolog system costs nothing, NU Prolog costs basically a handling fee to academic sites, and the price of SICStus Prolog to research sites is quite modest. What is more, two of the systems on the Sun here are in part derived from the "DEC-10 compatible" source code that I broadcast to the net in 1984: read, write, setof, &c. There is nothing comparable to that for the other dialects. Darn, I forgot ZYX ProLog; it belongs in the list of "haven't got it but all it takes is money". How about Waterloo Prolog? Well, in my 1984 report "On Standardising Prolog" I showed how a standard based on Edinburgh Prolog would be able to handle Waterloo Prolog, and a document on user-assigned stream aliases I posted to Roger Scowen recently explicitly considers Turbo Prolog. When it comes to books, Edinburgh Prolog books are most common, then Turbo Prolog (Why is the PC world so full of very thick books from a handful of publishers that tell you slowly, painfully, and confusingly what is said so much better in the manuals for the products they refer to?) then perhaps micro-PROLOG, and then is peters out to almost nothing. There is one book on Prolog III I know of, and one book which uses VM/Prolog. Nope, priority is not the most important criterion for standardising a programming language. The greatest good for the greatest number of users is. (I have an unpleasant feeling that my principles are about to force me to buy a copy of Turbo Prolog instead of borrowing an old manual. Ugh. Anyone got a recent Turbo Prolog they don't want?)
aarons@syma.sussex.ac.uk (Aaron Sloman) (11/19/89)
From the point of view of an organization (Sussex University) responsible for the implementation of a fairly widely used and commercially marketed Prolog system (i.e. the Prolog subsystem of POPLOG, marketed for us by Integral Solutions Ltd -- as a result of a management buy-out from SD-Scicon, the previous distributors) I must say that in general I find myself in total sympathy with Richard O'Keefe's comments. If Prolog were already so widely used that multi-million dollar business awaited the developers and implementors of Prolog systems, then production of a radically new standard for the language might be justified in that costs would be recovered. At present my impression is that NONE of the prolog vendors around the world would be in a position to afford major revision of the language along with software to help all their customers convert old code to the new language. There would be tremendous wasted effort with not much gain. So the effect could well turn out to be that vendors go on providing more or less the old version (with perhaps a few useful extensions) and that would remain the DE FACTO standard, making the official standard nothing more than an academic curiosity. I have not read the latest version of the new standard, but Richard's quotations and comments leave me feeling that it is likely to diverge far too much from the existing widely "agreed" de facto standard, and, as he points out, would break too much code. (Incidentally, the Poplog group used to have a representative on the BSI standard committee, but we lost interest when it seemed that the manpower cost of participating was not worthwhile in view of likely results.) Aaron
pgl@cup.portal.com (Peter G Ludemann) (11/20/89)
Two questions to Richard in OZ: Last time I checked - - blanks are not significant in ISO but they are signficant in "Edinburgh" [for example, to determine the meaning of comma in not (a,b) and not(a,b)] - the reference grammars (C&M, Quintus, BSI) all are ambiguous (at least, I couldn't figure out a way to make them LR(k) --- which is a pretty good test of ambiguity, I think) Comments? - peter ludemann --- my opinions are my own responsibility ---
ok@mudla.cs.mu.OZ.AU (Richard O'Keefe) (11/20/89)
In article <24257@cup.portal.com>, pgl@cup.portal.com (Peter G Ludemann) writes: > Two questions to Richard in OZ: > Last time I checked - > - blanks are not significant in ISO but they are > signficant in "Edinburgh" [for example, to determine > the meaning of comma in not (a,b) and not(a,b)] Unfortunately, I've packed the documents away in a couple of boxes to go back to Auckland, so I can't check the right answer. However, the claim "blanks are not significant in" WG17 Prolog is outrageously false, always has been, and always SHOULD have been. If you want a language where blanks are not significant, go use Fortran. Blanks are significant in English: light housekeeper \== lighthouse keeper a nice boat \== an iceboat Blanks are significant in Pascal. Blanks are significant in C. They are significant in COBOL, Ada, PL/I, Lisp, Pop, ML, you name it. (Think about x+++y in C. It's legal. And take a dekko at "preprocessor numbers" in the C standard.) This is one of the things which has changed quite often in BSI/WG17 Prolog. N40 does make blanks significant after integers, where they weren't before: 0x1 used to be the token 0 followed by the token x1. In document N40, this is a single hexadecimal number (1). (Why in the name of sanity did WG17 copy hexadecimal numbers from C when EXISTING Prolog systems allow any base from 2 (which I quite often use) to 36 (which is cute rather than useful)?) Similarly, given the declaration :- op(600, xfx, e). the character sequence 3e-22 unambiguously stood for e(3,-22) in Common Prolog, but in WG17 Prolog it stands for 3.0e-22, so you have to add spaces: 3 e -22. (I suspect that WG17 tokenisers won't be smart enough to treat 3e -22 or 3e- 22 as 3 e -22.) Again, what WG17 have done is to borrow syntax from C rather than from existing Prologs. WG17 _have_ done some things with operators, for example [this,is,an,example] is no longer legal. By the way, 'not' is not a predefined operator in WG17 Prolog and has no assigned meaning. (At least they haven't insisted on breaking NU Prolog and Quintus Prolog, where not/1 is sound (or, in Quintus's case, apologetic) negation.) The WG17 negation-as-failure form is 'fail_if'. Without N40 to check, I turned to some notes I made on how WG17 would break LPA Prolog. (That's Logic Programming Associates.) My summary was At a rough guess, for me, WG17/LPA syntax differences would show up about one per 70 lines, excluding if->then;else. (It is not just Quintus Prolog that WG17 would break, far from it!) But one difference I did _not_ list was the "not(" "not (" case. > - the reference grammars (C&M, Quintus, BSI) all > are ambiguous (at least, I couldn't figure out a > way to make them LR(k) --- which is a pretty good test > of ambiguity, I think) I was chagrined just now to discover that section 2-8 of the Quintus Prolog Reference Manual is explicitly headed "Formal Syntax". Of course it's only an INFORMAL formal syntax. It is there to help human readers, and is not runnable. Things like unit-clause --> head {where head is not otherwise a sentence} are clearly not part of a "REFERENCE grammar". (I just noticed that the grammar in 2-8-2 doesn't mention if->then;else at all. That will give you a clue as to how formal it is.) The grammar in section 2-8-3 is in rather better shape: the comments about operators and "(" are actually handled in the tokeniser: "p(" and "p (" are actually different sequences of tokens. Trying to make a grammar LR(k) is a pretty lousy way of testing whether an extensible operator-precedence language is ambiguous. We start with the simple fact that Prolog has 1201 priority levels (0..1200). LR(k) grammars can't handle parameters, so you essentially have to write out 1201 copies of the guts of the grammar. I admire the tenacity of anyone who did that. We then observe that the grammars you tend to see are mostly descended from the one in the DEC-10 Prolog manual, which didn't _try_ to be precise, so it fails to point out that "p(" and "p (" are actually two different token sequences which can be parsed unambiguously. We next note the distinction between a grammar being ambiguous and a language being ambiguous. No Prolog term is assigned more than one parse by the public-domain parser: the language is unambiguous. (But it is not LR(k) for any finite k.) It's worth reflecting that many programming languages aren't LR(k). Algol wasn't, Pascal isn't, C isn't, Modula-2 isn't, Ada isn't. You can get an LR(k) grammar for those languages using a very simple technique: you lie. I'm afraid I don't know which grammar Ludeman means by "the [BSI] reference grammar". There were several, and the one in WG17's N40 document is different again (and except for the excessive borrowing from C, it's a big improvement on earlier grammars). I'm quite sure that WG17 *intend* their grammar to be locally unambiguous: there are precisely two places where a Prolog parser has to make a choice": atom/prefix (which they've blocked by ruling that no operator can be taken as an atom unless it has parens directly around it) and infix/postfix (which they've blocked by making it illegal for an atom to be both an infix and a postfix operator). The grammar isn't suitable for LR parsing, but why should it be? It's an extensible operator-precedence language, and that's a heck of a lot SIMPLER to parse than an LR language.
karam@sce.carleton.ca (Gerald Karam) (11/21/89)
In article <1794@syma.sussex.ac.uk> aarons@syma.sussex.ac.uk (Aaron Sloman) writes: > ...some intro words deleted.... I >must say that in general I find myself in total sympathy with >Richard O'Keefe's comments. > >If Prolog were already so widely used that multi-million dollar >business awaited the developers and implementors of Prolog systems, >then production of a radically new standard for the language might >be justified in that costs would be recovered. 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. >At present my impression is that NONE of the prolog vendors around >the world would be in a position to afford major revision of the >language along with software to help all their customers convert >old code to the new language. There would be tremendous wasted >effort with not much gain. 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 :-). 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. >So the effect could well turn out to be that vendors go on providing >more or less the old version (with perhaps a few useful extensions) >and that would remain the DE FACTO standard, making the official >standard nothing more than an academic curiosity. with this many vendors behind it, i would be suprised if they don't back the standard. it's in their own interest. >I have not read the latest version of the new standard, but >Richard's quotations and comments leave me feeling that it is likely >to diverge far too much from the existing widely "agreed" de facto >standard, and, as he points out, would break too much code. 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? -gerald p.s. richard o'keefe is a contributer to WG17 by the fact that he posts constructive discussion on the net where he knows WG17 people are listening (reading?). since he knows they have thick skins, he doesn't worry about expressing his opinions in his unique style :-) p.p.s. anyone can contribute to WG17 just send in your opinion!
cdsm@sappho.doc.ic.ac.uk (Chris Moss) (11/21/89)
In article <2744@munnari.oz.au> ok@mudla.cs.mu.OZ.AU (Richard O'Keefe) writes: > I will be >very surprised indeed if the NZSI ever made any decision about Prolog as such >at all. No, Richard, I never claimed it did. Indeed I'd be surprised if it had. Because it decided not to be a member of SC22 I assume Prolog followed by default. > "Priority" is a total red >herring, here. If we went by priority, I think we'd have to go for the >Begriffschrift (sp?) -- I've been surprised that no-one has revived it as >a "graphical Prolog". Or GOLUX. A standard is for a PRACTICAL purpose. This is silly. Are you claiming that Edinburgh was the only practical Prolog system around? >The criterion which guides a standard is "what will maximise the practical >utility of this standard?" At the time that the BSI committee was formed, >the answer was clear: the Edinburgh branch of the Prolog family stood out >in terms of number of implementations that were intended to be compatible, >in terms of books in print or in progress, and in terms of public-domain >software coded in that dialect (the DEC-10 Prolog library). I think this is a biased view. If one was to judge simply by the number of sales, then probably in 1984 microProlog would have won hands down. As you point out, Turbo would probably win now. Are either of these relevant? Probably the only way in which Edinburgh was the clear winner then was in the sales of Clocksin & Mellish's book, which is different in some ways (e.g. operator definitions) from any widely used implementation. Unfortunately, nobody did a serious survey then to find out what was most widely acceptable, and so there was a lot of wrangling which, with hindsight, was very destructive. By the time a consensus emerged most of the good people had quit the committees. >Let's consider availability now, and see what it tells us about whether >a Prolog standard should resemble Edinburgh Prolog, or Turbo Prolog, or >Prolog III, or micro-PROLOG. I was NOT arguing NOW in favour of any other basis for the standard. I was talking about history and trying to explain to those who didn't know it why there had been so many different points of view. I made my point of view quite clear at the Seattle conference in 1988 and haven't changed it since, that I believe that using the Edinburgh definition is the only way a standard will be achieved. It has certainly been accepted in the English, Japanese and German speaking worlds. I don't think the French have been won over. I've used it almost exclusively for the last 3-4 years and we've switched in our teaching here at Imperial College (this year has completed the transition). So please don'tt make out I'm arguing for a position I don't hold. Chris.
ok@mudla.cs.mu.OZ.AU (Richard O'Keefe) (11/22/89)
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?
ok@mudla.cs.mu.OZ.AU (Richard O'Keefe) (11/22/89)
In article <1371@gould.doc.ic.ac.uk>, cdsm@sappho.doc.ic.ac.uk (Chris Moss) writes: > This is silly. Are you claiming that Edinburgh was the only practical > Prolog system around? and later > So please don't make out I'm arguing for a position I don't hold. > Chris. Ditto. > I think this is a biased view. If one was to judge simply by the number > of sales, then probably in 1984 microProlog would have won hands down. As > you point out, Turbo would probably win now. Is either of these relevant? *YES*. micro-PROLOG: I contended in 1984 that the standard should not be unduly influenced by micro-PROLOG because there wasn't any variation in the micro-PROLOG market (there weren't half a dozen nearly-but-not-quite- compatibles as there were for Edinburgh Prolog, so micro-PROLOG didn't *need* a standard) and because micro-PROLOG was different enough from Edinburgh Prolog that it wasn't worth trying to hybridise. I had then, as I have now, no influence on the committee, and they went on for at least a year trying to define Edinburgh Prolog on top of micro-PROLOG data structures. I think it is relevant to note that Logic Programming Associates now offer LPA Mac Prolog for the Mac and LPA Prolog Professional for the PC, and both are described by LPA as "Edinburgh" systems, although LPA Prolog Professional continues to support micro-PROLOG syntax as well. I did claim in 1984 that dialects other than Edinburgh Prolog should influence the standard in the sense that it should be considered how a compatibility package or translator could be written, and wrote a DAI report (title "On Standardising Prolog") which considered Waterloo Prolog. I didn't do that for micro-PROLOG because there were people at Imperial far better equipped to do that than I was. Turbo Prolog: Borland bought a system which was known not to be Clocksin & Mellish compatible and pushed it hard. If the official standard looks like the de facto standard at the time of their purchase and leaves them in the cold, (a) they knew what they were doing and (b) they did the same with Pascal and it doesn't seem to have stopped them. On the other hand, I repeat that my position remains what it was in 1984: it would be advisable to consider other dialects and be sure that they can be converted _somehow_. I recently sent a 20+ page document to Roger Scowen concerning a particular aspect of streams, and I explicitly and carefully considered Turbo Prolog when producing that design. > Probably the only way in which Edinburgh was the clear winner then was in the > sales of Clocksin & Mellish's book, which is different in some ways > (e.g. operator definitions) from any widely used implementation. Well, not the only way. DEC-10 Prolog was significantly superior in design to micro-PROLOG. (Frank McCabe said in a talk at Edinburgh that he adopted the everything-is-a-list syntax for micro-PROLOG in order to simplify the garbage collector, which he had to write in Z80 assembly code on a machine with essentially no development support.) [Let it be stipulated that NU Prolog is now considerably superior to DEC-10 Prolog in semantics, though some of the syntactic changes are for the worse.] There was also the fact that a goodly chunk of the DEC-10 Prolog system was sanitised and made public (read, write, setof, top level, how to do DEC-10 compatible see/tell/&c if you had streams, other stuff) so that anyone who wanted to be DEC-10 compatible got a free start. (SICStus Prolog made use of this, and SB Prolog has some of it.) _That_ is an important feature which micro-PROLOG did not have. There was also the DEC-10 library (get it from Edinburgh, folks, costs next to nothing) which was made available by FTP in the States; for no other dialect was a similar amount of leverage to be obtained from free code. The claim about operators is bogus. Clocksin & Mellish were quite careful about what they said. The description they give of operators in general is fine. There are three things: -- they don't say that you can have a list of atoms as the third argument of op/3 (you couldn't in PDP-11 Prolog) but they don't say you _can't_ -- they don't say that you can use a first argument of 0 to cancel an operator (you couldn't in PDP-11 Prolog) but they don't say you _can't_ -- they show operator numbers running from 1 to 255 (as in PDP-11 Prolog) but they said repeatedly that the range of numbers varied between systems, and only claimed that the relative order of the operators was conventional, and that order of operators _is_ still conventional. > By the time a consensus emerged most of the good people > had quit the committees. It shows.
cdsm@sappho.doc.ic.ac.uk (Chris Moss) (11/23/89)
In article <2780@munnari.oz.au> ok@mudla.cs.mu.OZ.AU (Richard O'Keefe) writes: >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. Quintus was obviously not itself a member of the BSI committee, or the ISO committee before the ANSI committee was formed, for obvious reasons. It's an American company (even if many of its members hot-footed it from Edinburgh!) But one should note: Several individuals from Quintus were on the mailing list for some time (including Richard of course) and they DID provide input. AI Ltd, the UK distributor for Quintus WAS on the BSI c'tee and if it didn't liaise with Quintus I'd be surprised. I refer to the companies, but in fact it's mostly individuals that are on committees. Chris Moss.
pgl@cup.portal.com (Peter G Ludemann) (11/23/89)
Richard O'Keefe states: > 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. Your prejudices are showing, Richard. 1. The `old Waterloo Prolog' is as `old' as Edinburgh Prolog and quite possibly better. It simply was on a less popular machine (for AI work) and wasn't pushed as vigourously by its creator. 2. If by `Prolog-like', you mean that IBM-Prolog uses `<-', `&' and '*' instead of `:-', `,' and '_', that's one of the finer distinctions I've ever run into. I personally think that the use of `&' is much nicer than `,' --- it avoids all the silly stuff about blanks being signficant in front of parenthesis (making Edinburgh-Prolog unique (I think) in this respect among all programming languages). 3. Anyway, the new IBM-Prolog supports multiple syntaxes, one of which is Edinburgh syntax. It also supports Edinburgh predicates. And it allows `mixed' programs, partly in IBM syntax and partly in Edinburgh syntax. 4. As to what is in IBM's best interest, I am not qualified to speak, but there are IBM employees in the standardisation group. - peter ludemann --- my opinions are my own responsibility ---
ssmith@joplin.mpr.ca (Shaun Smith) (11/25/89)
As one who programs in Prolog on a daily basis, I'd like to put my
two bits worth in about the BSI standardization.
I don't want to put words into Richard O'Keefe's mouth, and please
don't jump all over me for my possible misunderstanding of his position,
but after following the discussion of WG17, I find myself believing much of
what he's said. I want a standard that embodies what "most" people
believe to be "standard" prolog.
Now, again, no flames until I've fully explained myself. Yes, I
know there is no such thing as "standard" prolog or "common" prolog, but
somehow we all seem to know what that means.
As an example, let me tell you of a porting of a fairly large (~400k
of source) prolog program. This program was written with portability in
mind. The program was partitioned into "standard" prolog files and then
a set of files that contained dialect dependent code. In other words,
there was a large number of files that made up the core program and 2
files per prolog dialect. These files contained things like the usually
non-standard "statistics" predicate or it's equivalent in the various prolog
dialects. C-Prolog, Quintus Prolog, and Arity Prolog were originally
supported. We ported the program to BIM Prolog.
Now the point of this is, we were able to port this thing! I was
amazed, but the writers of the program were determined that it should be
portable, and be usable under different prologs on different platforms. In
other words, they were doing the right thing. All we did was write the
appropriate BIM Prolog specific file. By the way, all of these dialect
specific files were very short.
Here at MPR we've been developing a compiler and run time system
for a language developed in house. We are using Prolog and C (for
historical reasons) to do this. The very last thing management wants to
see is 8 months to a year of code suddenly become unsupported by most
Prolog vendors!!
Ultimately, the standard should please those that use prolog, and
whose business depends upon it. If the committee have ideas about what
prolog might best become, then I too think that they are free to write a
standard for that _other_ language.
I beg those on the committee to please consider those who stand to
lose the most by a standard that breaks all our code.
Shaun
Newsgroups: comp.lang.prolog
Subject: Re: More fun with WG17
Summary: Prolog for Users!
Expires:
References: <2609@munnari.oz.au> <696@sce.carleton.ca> <2643@munnari.oz.au> <715@sce.carleton.ca> <2780@munnari.oz.au> <1378@gould.doc.ic.ac.uk>
Sender:
Reply-To: ssmith@rhumba.UUCP (Shaun Smith)
Followup-To:
Distribution:
Organization: Microtel Pacific Research Ltd., Burnaby, B.C., Canada
Keywords: Prolog, WG17, Portability, Standards
As one who programs in Prolog on a daily basis, I'd like to put my
two bits worth in about the BSI standardization.
I don't want to put words into Richard O'Keefe's mouth, and please
don't jump all over me for my possible misunderstanding of his position,
but after following the discussion of WG17, I find myself believing much of
what he's said. I want a standard that embodies what "most" people
believe to be "standard" prolog.
Now, again, no flames until I've fully explained myself. Yes, I
know there is no such thing as "standard" prolog or "common" prolog, but
somehow we all seem to know what that means.
As an example, let me tell you of a porting of a fairly large (~400k
of source) prolog program. This program was written with portability in
mind. The program was partitioned into "standard" prolog files and then
a set of files that contained dialect dependent code. In other words,
there was a large number of files that made up the core program and 2
files per prolog dialect. These files contained things like the usually
non-standard "statistics" predicate or it's equivalent in the various prolog
dialects. C-Prolog, Quintus Prolog, and Arity Prolog were originally
supported. We ported the program to BIM Prolog.
Now the point of this is, we were able to port this thing! I was
amazed, but the writers of the program were determined that it should be
portable, and be usable under different prologs on different platforms. In
other words, they were doing the right thing. All we did was write the
appropriate BIM Prolog specific file. By the way, all of these dialect
specific files were very short.
Here at MPR we've been developing a compiler and run time system
for a language developed in house. We are using Prolog and C (for
historical reasons) to do this. The very last thing management wants to
see is 8 months to a year of code suddenly become unsupported by most
Prolog vendors!!
Ultimately, the standard should please those that use prolog, and
whose business depends upon it. If the committee have ideas about what
prolog might best become, then I too think that they are free to write a
standard for that _other_ language.
I beg those on the committee to please consider those who stand to
lose the most by a standard that breaks all our code.
Shaun
Shaun M. Smith | ssmith@joplin.mpr.ca
Microtel Pacific Research | joplin.mpr.ca!ssmith@uunet.uu.net
8999 Nelson Way, Burnaby, BC | ssmith%joplin.mpr.ca@relay.ubc.ca
Canada, V5A 4B5, (604) 293-5345 | ...!ubc-vision!joplinmpr.ca!ssmithjeff@aiai.ed.ac.uk (Jeff Dalton) (12/27/89)
In article <1359@gould.doc.ic.ac.uk> cdsm@doc.ic.ac.uk (Chris Moss) writes: >Thus the portmanteau approach of Common Lisp would have been a more >appropriate model than "do it the Edinburgh way". You still seem to think Common Lisp solved all conflicts about how to do X by including all ways to do X. That is simply not true. Common Lisp is closer to "do it the MIT way" than you seem to think.