jeff@aiva.ed.ac.uk (Jeff Dalton) (08/17/88)
In article <2546@mandrill.CWRU.Edu> leon@alpha.ces.cwru.edu () writes:
] There will be a panel discussion at the Logic Programming Conference
] at Seattle on the Prolog Standard.
] Topic: A Standard for Prolog: The Current Reality
] Speakers:
] Dr P. Deransart, INRIA, France
] Dr R. O'Keefe, Quintus Computer Systems, USA
] A. Turk, Applied Logic Systems, USA
] Dr D.S. Warren, SUNY-Stonybrook, USA
Note that most speakers are listed as USA, but the US is hardly
participating in the ISO standards work at all. Since many people
in the US may not like the result, they may end up regretting this.
Can anyone say why almost no one in the US seems interested in
working on the standard? Are the companies that sell Prolog systems
hoping they can just ignore the standard?
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Daltonok@quintus.uucp (Richard A. O'Keefe) (08/20/88)
In article <528@aiva.ed.ac.uk> jeff@uk.ac.ed.aiva (Jeff Dalton,E26 SB x206E,,2295119) writes: >In article <2546@mandrill.CWRU.Edu> leon@alpha.ces.cwru.edu () writes: >] Topic: A Standard for Prolog: The Current Reality >] Speakers: >] Dr P. Deransart, INRIA, France >] Dr R. O'Keefe, Quintus Computer Systems, USA >] A. Turk, Applied Logic Systems, USA >] Dr D.S. Warren, SUNY-Stonybrook, USA > >Note that most speakers are listed as USA, but the US is hardly >participating in the ISO standards work at all. Since many people >in the US may not like the result, they may end up regretting this. >Can anyone say why almost no one in the US seems interested in >working on the standard? Are the companies that sell Prolog systems >hoping they can just ignore the standard? To answer the last question first, it is not the companies which sell Prolog systems which decided not to participate. In order to be "on" an ISO panel, you have to have been sent by your national standards organisation. For Quintus, say, to have a representative on the ISO committee would mean that we would have to get ANSI to agree that it was a good idea to have ANSI participation. They never asked _us_. (Anyone know who they _did_ ask?) Apparently, ANSI think that a Lisp standard and a Scheme standard are enough. The list as quoted is missing one member: Chris Moss. I've just come back from ICLP '88, so I can give you one-line summaries of what was said: Moss: I have resigned from the committee and don't like what they are doing. Deransart: A standard should be based on a formal specification and here's what ours looks like (faint blue slides). Me: There should be a standard but the BSI work is not good. Turk: We Prolog vendors need a standard. Warren: A standard is not needed. To the extent that there was a consensus (and the exchanges were frank, bordering on direct) it was that a standard would be a Good Thing, and that a voluntary specification produced by people who knew what they were doing might be a good idea. Chris Moss having resigned from the committee, my one-way wager of $100 becomes void. I don't imagine that anyone else is likely to do better than he was: the requirements were flawed.
jeff@aiva.ed.ac.uk (Jeff Dalton) (08/24/88)
In article <297@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >To answer the last question first, it is not the companies which sell >Prolog systems which decided not to participate. In order to be "on" >an ISO panel, you have to have been sent by your national standards >organisation. For Quintus, say, to have a representative on the ISO >committee would mean that we would have to get ANSI to agree that it >was a good idea to have ANSI participation. They never asked _us_. Perhaps I should have stated the problem more clearly: the problem is that there is no US national level work on Prolog standards, which is what allows US participation in ISO work. In other words: why is there no Prolog equivalent to x3j13 or x3j11? My understanding was that no one had been very interested. Perhaps this is wrong and the real problem is that no one knows how to go about it. (Note here that there is a difference between getting ANSI to agree and ANSI never asking -- I don't think there is anything actively working to prevent US work on Prolog standards.)
jtr@cs.exeter.ac.uk (Jason Trenouth) (11/16/89)
> You're going to love this one, I can tell. ... I always look forward to Lensman O'Keefe's informative regular postings on the emerging Prolog standard. His criticisms of the output from the standard making committee have wetted my appetite. Is it possible to hear more (on the net) about how it was set up, who is currently on it, what their affiliations are, and so on. JT -- ______________________________________________________________________________ | Jason Trenouth, | JANET: jtr@uk.ac.exeter.cs | | Computer Science Dept, | UUCP: jtr@expya.uucp | | Exeter University, Devon, EX4 4PT, UK. | BITNET: jtr%uk.ac.exeter.cs@ukacrl|
dave@quintus.UUCP (David Bowen) (06/27/90)
In article <3319@goanna.cs.rmit.oz.au> Richard A. O'Keefe writes: >The ISO committee decided that they didn't _want_ me to be involved in >the construction of a standard, so I can be as vehement as I like. Of course you can be as vehement as you like. I was only pointing out that it isn't helpful. The ISO committee decided no such thing. Roger Scowen, chair of the committee and one of the project editors, has repeatedly stated that he wants your involvement. >> The only way to achieve a standard soon is to restrict it to very >> little more than was in DEC10 Prolog, which is very close to being >> a subset of most of the Prolog implementations available today. > >That means dropping floats, streams, and error handling. >Going for a "minimal" standard was a very silly idea back in 1985; I don't mean THAT minimal. Floats and streams should clearly be in the standard. Error-handling is in the current proposal, but I think it needs some work. Modules are clearly desirable but no consensus exists on what they should look like. >(I warn readers, putting together a workable >specification for floating-point arithmetic is _not_ a trivial matter; >it's not a _small_ extension to DEC-10 Prolog if you want to get it right.) Thanks for the warning. I'm sure that the ISO committee would welcome a proposal from you on this. >With respect to bignums, we are talking about a feature > -- which is present in Prolog's competitors, Lisp, Scheme, Haskell, &c > -- which is present in several existing compatible Prologs (PopLog, > ZYX Prolog, Xerox Quintus Prolog, presumably others) > -- which is already available to C programs under BSD Unix > -- the implementation of which is described in great detail > in Knuth volume 2 and in other textbooks > -- the point of which is to ensure that Prolog programs performing > arithmetic get _correct_ answers. I think that there are a number of other features for which equally strong arguments could be made. Two questions are: how long do we want to go on debating/specifying all these extra features, and how much burden do we want to put on implementors. You may argue that the latter should not be a consideration, but a lot of implementors are represented on the committee. If there are a lot of Prolog users out there who really want bignums (or whatever other feature), they ought to get involved in the standardization effort and push for them. >What's needed is >a committee who are vehemently interested in doing a high-quality job. You should start attending the meetings.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (06/28/90)
In article <1389@quintus.UUCP>, dave@quintus.UUCP (David Bowen) writes: > In article <3319@goanna.cs.rmit.oz.au> Richard A. O'Keefe writes: > >The ISO committee decided that they didn't _want_ me to be involved in > >the construction of a standard, so I can be as vehement as I like. > The ISO committee decided no such thing. Roger Scowen, > chair of the committee and one of the project editors, has repeatedly > stated that he wants your involvement. Roger Scowen is not the committee. The proposal to have me involved in the standard was in fact rejected by a meeting of the ISO committee, or so I have been informed. ALP(UK) and BSI say they are still interested, but again, they are not ISO. This newsgroup is not a meeting of the ISO or any other standards committee. What is proper/helpful in this newsgroup is not necessarily what is proper/helpful at a standards meeting. I really don't understand why an expression of my personal preference about what should be in the standard is being flamed, before flaming someone with no power or influence, why not flame some of the ISO delegates who in attempting to make sweeping changes have held things up so long? I was, after all, saying no more than that a feature which is _present_ in a Quintus product would be good to have in a standard, it's hardly a sweeping change... > >That means dropping floats, streams, and error handling. > >Going for a "minimal" standard was a very silly idea back in 1985; > I don't mean THAT minimal. But extreme minimality has long been a goal of the BSI/ISO committee, one of the few explicit principles that has ever been adopted. That's why they have @> /2 but not compare/3, and surely that's why they recently dropped strings. > Floats and streams should clearly be in the standard. Why is it "clear" that floats and streams should be in but correct integer arithmetic should not? Providing correct integer arithmetic requires no changes to the syntax of the language or the number, names, or interfaces of built-in predicates, and the absence of machine-dependence would make the standard _simpler_ and user programs more portable. I'm not against floats or streams, far from it. But let's get real about this: writing the streams _proposal_ that Dave Bowen and I put together required more hard thought than _implementing_ bignums. (The file LONG.PL in the DEC-10 Prolog library is in the public domain, and could be used behind-the-scene in exactly the same way that ALS Prolog on PCs implements double precision floats as compound terms behind-the-scene.) > >(I warn readers, putting together a workable > >specification for floating-point arithmetic is _not_ a trivial matter; > >it's not a _small_ extension to DEC-10 Prolog if you want to get it right.) > Thanks for the warning. I'm sure that the ISO committee would welcome a > proposal from you on this. I _sent_ a draft proposal last year. It's available as an Auckland University Computer Science report. It needs work. In particular, it needs to be reconsidered in the light of the proposal currently before ANSI for a meta-standard for the floating-point part of programming language standards. > I think that there are a number of other features for which equally strong > arguments could be made. Two questions are: how long do we want to go on > debating/specifying all these extra features, and how much burden do we want to > put on implementors. You may argue that the latter should not be a > consideration, but a lot of implementors are represented on the committee. I keep on stressing that bignums are *EASY* to implement. How that gets perceived as "arguing that [the burden put on implementors] should not be a consideration" is a mystery to me. There has never been ANY *reported* debate about bignums from the standards committees, in the documents I have received in BSI/ISO mailings, I have never seen any argument whatsoever advanced against correct integer arithmetic. > >What's needed is > >a committee who are vehemently interested in doing a high-quality job. > You should start attending the meetings. (a) When I worked at Quintus, some people senior to me repeatedly told me to stop wasting time reading and responding to BSI/ISO documents. (b) Now that I am working at an Australian University, my income is approximately 60% of what it was at Quintus. Meetings are timed for the convenience of Northen Hemisphere delegates, so I'd have to take time (and pay) off to attend them. I am not _motivated_ by money, but it _does_ affect what I can afford to do. I would like to point out that this is precisely why there is so little user involvement in the Prolog standard, the vast majority of the people who will be affected by the standard cannot afford to go to the meetings. I have in the past volunteered in this newsgroup to manage an Australian mail server for standards documents if given machine-readable copies that could be made available that way. I remember how it _was_ feasible for ordinary people to participate usefully in the Ada standardisation process, and I'm aware of how ordinary people are currently able to find out what the current state of the Ada9X work is and to ask questions and make suggestions. Making the information legally available for mail- server access and comment would be a lot more useful than telling people to go to the meetings. (Unless that was an offer to pay my expenses?) -- "private morality" is an oxymoron, like "peaceful war".
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (06/28/90)
In article <1389@quintus.UUCP>, dave@quintus.UUCP (David Bowen) writes: [ in response to my statement that Robin Popplestone is *RIGHT* that correct integer arithmetic is a Good Thing, and my further claim that correct integer arithmetic ought to be in the Prolog standard. ] > arguments could be made. Two questions are: how long do we want to go on > debating/specifying all these extra features, and how much burden do we want to > put on implementors. I have also received E-mail in which I was asked Indeed [bignums are in Lisp, Haskell, and so on], but [it is] hard to find a public and portable implementation of bignums that I can use in my own scheme for example. Any ideas ?? As it happens, I have sources for more Scheme systems than I know what to do with. One of them is ELK. Here is the file ORIGIN from the source distribution of ELK 1.0. This software is Copyright 1987, 1988, 1989, Nixdorf Computer AG and Teles GmbH, Berlin. This software has been written by Oliver Laumann (me) for TELES Telematic Services, Berlin, in a joint project between TELES and Nixdorf Microprocessor Engineering, Berlin. I would like to thank Claus Bathe of NME Berlin for securing the permission from his management to publish this software, Prof. Dr. Sigram Schindler for providing the work environment for ISOTEXT and Elk, and Carsten Bormann for his support and src/bignum.c. ^^^^^^^^^^^^ Any use of this software is permitted provided that this notice is not ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ removed and that neither Oliver Laumann nor TELES nor Nixdorf are deemed to have made any representations as to the suitability of this software for any purpose nor are held responsible for any defects of this software. THERE IS ABSOLUTELY NO WARRANTY FOR THIS SOFTWARE. Berlin, July 1, 1989 Oliver Laumann net@TUB.BITNET net@tub.UUCP That's not the only bignum package I have, but it's the one with the least restrictive copyright. (Oaklisp is covered by a GNU-style "copyleft", and I've not got that on-line.) elk/src/bignum.c is about 660 lines of fairly clear well-laid-out C code. If the extra functions needed for Prolog (mainly the bitwise operations) were added, and some of the ELK-specific stuff were stripped out, it might come to 700 lines. I would of course be reluctant to suggest enlarging PC Prologs, but for one fact: the major limitation on the ones I know about is not the size of the support code, but the size of the Prolog stacks. By allowing bignum arithmetic to be implemented at a lower level than library(long) and perhaps even allowing bignum bodies to be stored in another stack entirely, bignum support would mean that PC Prologs could handle BIGGER problems than they now can by using library(long). And the code is ALREADY available at the price of an acknowledgement! (At least one of the PC Prologs I know about currently switches from one representation to another when the 16-bit limit is reached _anyway_, the snag is that they switch to float and start producing wrong answers...) -- "private morality" is an oxymoron, like "peaceful war".
dave@quintus.UUCP (David Bowen) (06/29/90)
In article <3330@goanna.cs.rmit.oz.au> Richard A. O'Keefe writes: >Roger Scowen is not the committee. The proposal to have me involved in >the standard was in fact rejected by a meeting of the ISO committee, or >so I have been informed. ALP(UK) and BSI say they are still interested, >but again, they are not ISO. BSI may send anyone it likes to the ISO committee meetings as a part of its delegation. You don't need any invitation from the ISO committee. If there was any problem with the BSI route, I expect that you could arrange with the convenor to attend as an observer. >I _sent_ a draft proposal last year. It's available as an Auckland University >Computer Science report. It needs work. In particular, it needs to be >reconsidered in the light of the proposal currently before ANSI for a >meta-standard for the floating-point part of programming language standards. Good. I hope that you will follow up on this. (Was this issued as an ISO document?) >(a) When I worked at Quintus, some people senior to me repeatedly told me > to stop wasting time reading and responding to BSI/ISO documents. It is true that we have changed our opinion of the Prolog standardization process over the last 5 years or so. At one time there did not seem to be much probability of convergence on any kind of a reasonable standard. Now there is a strong likelihood of a standard which is not too far from "common Prolog". >I have in the past volunteered in this newsgroup to manage an Australian >mail server for standards documents if given machine-readable copies >that could be made available that way. I don't see why documents couldn't be posted directly on this news group.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (06/29/90)
In article <1391@quintus.UUCP>, dave@quintus.UUCP (David Bowen) writes: > In article <3330@goanna.cs.rmit.oz.au> Richard A. O'Keefe writes: > >I have in the past volunteered in this newsgroup to manage an Australian > >mail server for standards documents if given machine-readable copies > >that could be made available that way. > I don't see why documents couldn't be posted directly on this news group. They would *still* have to be archived somewhere. What about someone who joins the net a month after something has been posted? If he's unlucky, he never hears about it until it's much too late. If *we're* unlucky, we get lots of messages "I missed X, can it be reposted" and someone is _sure_ to oblige... Having one site each in the US, Australia, Europe, and Japan where people could FTP the latest drafts of things (or get them via a mail- server) would cut down international net use quite a bit. The real problem is a legal one. Drafts of the C standard were *not* made available for legal reasons. I don't know what the ISO rules are. Working documents _other_ than drafts of a standard are presumably not a problem, the copyright would remain with the authors and they could be asked to agree to eletronic distribution as well as paper distribution. But presumably the copyright of drafts of the standard belongs to ISO. Drafts of the standard need to be subjected to two kinds of criticisms. 1) They need to be scrutinised very carefully for technical errors. 2) People who are trying to _use_ Prolog need to check whether the standard meets their needs. Currently, there is a de facto standard (C Prolog minus a few bits). At the moment I have access to 6 Prolog systems which are pretty close to that. (I also have C Prolog itself on a tape somewhere, and expect to pick up another portable Edinburgh-compatible Prolog fairly soon.) I also have manuals for IBM Prolog, ZYX Prolog, and Quintus Prolog, and keep meaning to ask for an Arity manual. The one thing which is in the current draft of the standard (given that strings have been dropped) but not in these Prologs is exception handling, and in fact most of them have it. The degree of similarity between these systems (except IBM Prolog) is *already* about as close as we could hope for from the current standard. And it just isn't good enough. Let me give you one specific example. What one writes as :- dynamic p/1, q/2. in SICStus Prolog has to be written as ?- dynamic([ p/1, q/2 ]). in NU Prolog, and some of the other systems I have access to are deeply unhappy with _either_ form. Some systems like ALS Prolog don't strictly speaking _need_ :- dynamic declarations, but it is a pain that they don't accept and _ignore_ them. The standard ought to require that every conforming Prolog implementation MUST accept some kind of declaration (I would even settle for ?- declare(dynamic, [ p/1, q/2 ]). as long as _everything_ accepted it) and that it MUST be legal to change a predicate thus declared, but in order to accomodate ALS Prolog all it has to do is _not_ say that that predicates _not_ declared :- dynamic _can't_ be changed. As it is, I have to load a DYNAMIC.PRO file first thing, and keep forgetting it. If you sit and stare at the text, this kind of thing isn't obvious. If you are actively trying to write code that will portable between several dialects, this kind of thing hits you in the eye right away, and you look to the text to see how it helps, and find that it doesn't. It was always important to ensure that people *using* Prolog would see whether the standard met their needs. A minimal standard doesn't. The bottleneck is not the technical difficulty of getting a workable standard done in time, but delegates' willingness to study the needs of Prolog _users_. -- "private morality" is an oxymoron, like "peaceful war".
jeff@aiai.ed.ac.uk (Jeff Dalton) (07/10/90)
In article <1385@quintus.UUCP> dave@quintus.UUCP (David Bowen) writes: >In article <3314@goanna.cs.rmit.oz.au> Richard A. O'Keefe writes: >... >>I agree _vehemently_ that bignum and rational arithmetic ought to be >>in the Prolog standard. >(Vehemence is not helpful in the construction of a standard.) Well, that could just as well be said to a number of people other than Richard. I don't think it's been a lack of vehemence that's delayed the Prolog standard. >I think it is important to have a Prolog standard sooner rather than later. >This is not going to happen if people keep widening the scope of what must >be in the standard. The only way to achieve a standard soon is to restrict >it to very little more than was in DEC10 Prolog, which is very close to being >a subset of most of the Prolog implementations available today. I agree, on this and the rest of the article. However, given the amount of time that has already been spent on the Prolog standard, I think it could be argued that, had the time been used more effectively, certain extentsions would not have delayed it overmuch. Unfortunately, some people have not wanted to standardize "Edinburgh Prolog" and have even spent a fair amount to time arguing that there isn't any such thing, sufficiently well-defined. Some have even tried to discredit Richard by pointing out that (at the time) he worked for Quintus. And, of course, some people cannot rest until their notion of modules (or whatever) is put into the standard. -- J