Path: utzoo!attcan!uunet!ogicse!ucsd!usc!apple!sun-barr!newstop!sun!quintus!dave
From: dave@quintus.UUCP (David Bowen)
Newsgroups: comp.lang.prolog
Subject: Re: Prolog standard
Message-ID: <1389@quintus.UUCP>
Date: 27 Jun 90 04:26:39 GMT
References: <15581@dime.cs.umass.edu> <3314@goanna.cs.rmit.oz.au> <1385@quintus.UUCP> <3319@goanna.cs.rmit.oz.au>
Reply-To: dave@quintus.UUCP (David Bowen)
Organization: Quintus Computer Systems, Inc.
Lines: 52

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.