Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!uunet!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.lang.prolog
Subject: The BSI/ISO Prolog standarisation "work"
Message-ID: <2531@munnari.oz.au>
Date: 26 Oct 89 05:15:03 GMT
Sender: news@cs.mu.oz.au
Lines: 168

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.