🚀 go-pugleaf

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?