ok@cs.mu.oz.au (Richard O'Keefe) (10/26/89)
It has been made clear to me that some people have misunderstood the point
of my posting about floating-point and the substandard. Even someone at
Quintus who should have remembered that I have _wanted_ a standard since
before the BSI "work" started accused me of "still trying to kill" the BSI/
ISO stuff. As it happens, I am a realist. It has always been clear to me
that the BSI/ISO efforts were unstoppable, simply because the BSI and the
ISO are _official_ standards bodies. I haven't got the kind of political
power that it would take to stop something like that, no matter how harmful
it may be. I did at one time have the hope that an ANSI standard might be
formed which would act as a counterpoise, but while there is apparently to
be some ANSI involvement it will not be in opposition (after the X3J3
business, ANSI are not likely to want to tread on ISO toes a second time).
So here is a "mini-manifesto" to explain why I post about the substandard
from time to time, and what I hope to accomplish by such postings.
1. I believe that the purpose of a standard for an EXISTING language such
as Prolog is to protect the interests of Prolog USERS. Not academics,
not Prolog vendors, not international organisations, but USERS. You.
Anyone who has bought a Prolog system. Anyone who has invested time
and effort in developing applications in Prolog.
I believe that in order to protect the interests of Prolog users, a
standard should have the following properties:
(1) It should provide the clearest possible guidance to Prolog
implementors to ensure that different Prologs are compatible.
It is not so important that Prolog users should find the standard
easy to read; books explaining the standard can come along later.
It's the implementors who must all understand the text the same way.
(2) It should preserve the existing language as much as possible.
It is not only inavdisable to change the meaning of built-in
operations such as atom/1 (now changed back) or @</2 (still
different), it is immoral. People who have made a serious
attempt to write portable programs should not have their
programs broken by a group of people they have never even met,
still less _asked_ to break their programs.
Prolog is not an ideal language. There are several things in it
that I would like to "fix" if I had my way. But it is not the
job of a standards committee for an existing language to "fix"
things, especially when there is no agreement about which parts
are broken.
(3) Such innovations as the committee is forced to make should be of
the highest technical quality. The names of operations should be
carefully chosen. Consistent names should be used (the current
standard violates this flagrantly: strings are sometimes called
"string", sometimes "str", and sometimes "", and strings aren't
all).
(4) A standard has to deal with two kinds of portability issues:
(a) differences between existing implementations
These differences are easily noticed by comparing manuals.
It is worth noting, however, that the differences which really
hurt sometimes aren't the ones that you notice most in the
manual. The difference between BIM's own syntax (which they
support as well as an ``Edinburgh'' syntax) and DEC-10 syntax
is extremely noticeable, but is very easy to overcome. In
contrast, a program which was written for a system which
indexes dynamic code may need extensive changes when ported
to a system which does not index dynamic code, and the places
the need to change may be hard to find.
(b) differences between Environments
Here we are concerned with things like EBCDIC/ASCII/ISO8859/
Mac/PC character sets, floating-point parameters, file system
interface, memory limits, and so on.
In both cases, the only reliable guide is to write programs and
try to port them. MACHAR, which I posted about, is a case in point.
As soon as I seriously tried to port an interesting (albeit tiny)
floating-point program between Prolog systems, I enountered problems
which the BSI/ISO committee have never addressed. Similarly, as
soon as you try to port a Prolog program which manipulates file
names from UNIX to MSDOS to VMS ... you encounter problems which the
BSI/ISO committee have never addressed.
2. I believe that the BSI/ISO committees are not acting in the interests
of Prolog users. I proposed that the BSI committee should explicitly
adopt the guiding principle of X3J11 (the C committee) that ``working
programs should not be broken without extremely good cause'', and the
BSI committee explicitly rejected the principle. For every issue the
question asked is not ``what are Prolog users currently relying on''
but ``what would we (the committee) prefer''. The committee have a
history of ``fixing'' things which were not broken. (For example,
making atom(X) abort with an error when X is a variable, changing the
name of findall/3 to bag/3, I could list many other examples.)
Not only have the committees innovated where no innovation was needed,
they have failed to innovate where the need was urgent. (Well, there
isn't any need to _innovate_ exactly, plagiarism is what's called for.)
An example: input/output is still tied far too closely to the UNIX/
MS-DOS model. (It is no co-incidence that the I/O part of the standard
for several years resembled a certain PC Prolog far more than it did
DEC-10 Prolog or C Prolog.) The underlying assumptions simply are not
true in VMS or CMS or MVS or several other file systems, and can't really
be relied on in practice in UNIX or MS-DOS.
As a result of trying to port some Prolog code between
(a) A Prolog system which does first-argument indexing on both static
and dynamic code
(b) A Prolog system which does first-argument indexing on static code
but not dynamic
(c) A Prolog system which does half-baked first-argument indexing on
static code (some terms with different functors are not distinguished)
(d) A Prolog system which normally does no indexing at all, but offers
half-baked indexing as a feature of a separate "optimising" compiler
which won't fit on the machine I was using
(all four of these systems billed themselves as "Prolog compilers")
it has become clear to me that where-you-need-to-put-the-cuts is a very
important portability problem. Code which needs no cuts at all in, say,
SICStus Prolog, and which was completely determinate, needed dozens of
cuts in (c). What makes this a really nasty portability problem is that
if you leave out the (green) cuts, the code is still correct, it just
runs out of memory on even trivial problems. First-argument indexing is
not *enough*. By now, it is the bare *minimum* we ought to be able to
rely on. My point here is that this doesn't _look_ like a problem from
the ivory tower, but it is something that bites you _hard_ as soon as
you seriously try to port Prolog code from a workstation to a PC.
First-argument indexing of static code is not an innovation in itself,
but insisting on it as part of the language would be.
3. As mentioned above, there are several areas (floating-point, file names,
I/O, cuts) where portability problems bring themselves forcibly to your
attention as soon as you make a serious attempt to port Prolog programs
between operating systems and machines. I mean that these problems hit
you on day ONE. From the fact that the standards committee have yet to
address these problems, I conclude that either
(a) helping Prolog users write code which can be ported between
different environments is not one of their primary aims, or
(b) they have never made any serious porting attempts themselves
and so don't know what the problems are.
From the fact that the committees have been continuing for some years
to ignore these problems, apparently with a quiet conscience, I
conclude further that
(b') they don't _know_ that they don't know what the problems are.
4. As a consequence of all the above, I believe that if the committee are
left to themselves, they will produce a standard which is pleasing to
them but which breaks existing code without solving any of the
"environment" portability concerns. That would be very bad indeed; so
I _cannot_ remain silent about it in good conscience. I hope to gain
two things from these postings:
(A) I hope to alert you to the fact that *your* interests as a Prolog
user are not being protected by the standards committees. I want
*you* to be sufficiently alarmed to find out for yourself what is
happening, and to take steps to ensure that your interests _are_
considered.
I keep arguing for what _I_ _believe_ are the interests of Prolog
users. But you didn't appoint me to represent you any more than
you appointed any of the committee members (no, I am not a member
of either committee, and *cannot* be). *You* have to get involved,
and frightening you by telling the truth about the substandard is
my way of trying to get you interested.
(B) I hope to shame the standards committees into becoming competent.
As things stand, I can hold them up to ridicule any time merely
by quoting from the current draft (it never fails). Once the
committees REALISE that I can make them look bad just by pointing
out, for example, that they have dropped _ // _ and compare/3
from the language, perhaps they will stop doing things like that
and perhaps they will do better.
Enough.