🚀 go-pugleaf

I wrote
>The one and only
>legitimate concern of the committee is to standardise the Prolog
>programming language more or less as it stands.  What Prolog _is_ is
>not a matter for philosophy, but for empirical investigation.  

In article <1281@quintus.UUCP>, dave@quintus.UUCP (David Bowen) writes:
> I totally agree with this and also think that it is a valid criticism of
> the work done by the committee so far. ...  On the other hand,
> standardization *entirely* by empirical investigation is not practical.
> Would we standardize on whatever is used by the largest number of people?
> Would we include Turbo Prolog?

If we standardised on whatever was used by the largest number of
people, we'd probably pick DBASE III.  The original terms of reference
for the BSI committee had them promising to develop something like what
Clocksin & Mellish described; it is only _necessary_ to investigate
Prologs which are "Clocksin & Mellish compatible".  (Which certainly
means PopLog, by the way.)  However, it would be wise and courteous to
look at other Prologs.  One of the documents I wrote in 1984 was a study
of Waterloo Prolog, which is not C&M compatible, and the document showed
that the evaluable predicates I had previously proposed weren't quite
enough to support a Waterloo compatibility package, and suggested a few
more which would get you most of the way.  So my own opinion on this is

	YES, someone on WG17 *SHOULD* look hard at Turbo Prolog,
	and should write and distribute a document which at least
	outlines how Turbo Prolog programs can be converted to WG17 Prolog.

It's not necessary to include Turbo's types and modes in WG17 Prolog.
However, I believe that Turbo Prolog has strings of a sort, and that
being so, that is one of the most powerful arguments I know why WG17
Prolog should have strings.  (I detest strings -- they are not at all
an efficient way of handling text.  Come to that, I detest Turbo Prolog.
But the people who bought it deserve _some_ consideration.)