Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.prolog
Subject: Re: BSI Prolog terms of reference
Message-ID: <945@cresswell.quintus.UUCP>
Date: 7 May 88 05:22:30 GMT
References: <831@cresswell.quintus.UUCP> <249@gould.doc.ic.ac.uk> <280@gould.doc.ic.ac.uk>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 179
Keywords: promises

In article <280@gould.doc.ic.ac.uk>, cdsm@ivax.doc.ic.ac.uk (Chris Moss) writes:
> As I said in my note to Jeff Dalton, Edinburgh is not the only source
> of inspiration to either the BSI or ISO group. It may have been at
> the beginning but we have for sometime been committed to at least two
> and maybe more syntaxes. If you disagree with that then say so.
> Incidentally, the ISO document also references Clark & McCabe as well
> as Clocksin and Mellish.

It doesn't really matter where you get your inspiration from.
The principal "inspiration" behind my 1984 document PS/6 was a draft
of Common Lisp.  Let me offer an analogy:  Icelandic and English are
very closely related languages.  Sigma Prolog and "Edinburgh" Prolog
are closely related languages.  If someone were designing a standard
for English (which heaven forbid) it would make sense to look to
Icelandic (and German and Dutch and French) for inspiration.  If
someone were pretending to design a standard for "Edinburgh" Prolg
it would make sense to look to Sigma Prolog (and LM Prolog and
Waterloo Prolog and Common Lisp) for inspiration.  It would NOT make
sense to adopt large chunks of Icelandic orthography and syntax as
part of the English standard.  It would not make sense to adopt large
chunks of Sigma Prolog as part of a standard which was claimed to be
based on "Edinburgh Prolog".  It isn't just that Sigma Prolog acted as
a source of inspiration:  there was a time when the basic data structures
the fragments talked about (e.g. compound terms being PAIRS consisting
of a function symbol and a TUPLE) were the data structures of Sigma Prolog,
not the data structures of any "Edinburgh" Prolog.

> OK, here is the position on the type predicates (atom, integer etc)
> as far as I can determine it. I can't quote chapter and verse on
> everything.  The issue arose because the French (I believe  JF
> Piques, possibly van Canegham and Roussel, but it was mediated
> through AFNOR) objected to having type predicates that fail when a
> variable is uninstantiated. It was decided to allow an error message
> in this case AS A COMPILER OPTION. Subsequently this was changed to
> being a switcheable option. The current version does not make it the
> default (I'm not totally sure on this).

This is not what any of the current fragments say.  The formal specification
and the radically informal "built-in predicates" document both say quite
unambiguously that the type testing predicates must UNCONDITIONALLY
report an error when passed a variable.  There is not the shadow of a hint
in either document that this might be suppressible.

> Now I doubt that that satisfies anyone. Obviously AFNOR would like 
> coroutining in the standard, and I personally interpret their
> position as a roundabout argument for this; ie. type predicates
> should suspend if their arguments are uninstantiated. Failing is
> WRONG and therefore they would like to be able to run on sequential
> machines keeping the sense of the predicates.

NU Prolog has already solved this problem, as I believe I have explained
before.  (If people are going to allow other random languages to
infiltrate the Prolog standard, why not NU Prolog, which manages to do a
fine job of coroutining with out introducing gratuitous incompatibilities?)
Their solution was to have two sets of type testing predicates:
a compatible set which behaves *exactly* as in other Edinburgh Prologs,
and a coroutining set.

Having fundamental operations whose effect cannot be determined by looking
at the code is, um, not a good idea.  Actually, it is a very BAD idea.
A language where "+" sometimes meant "-" depending on a run-time switch
is not a language I would care to program in.  A language where it is a
compile-time option is little better.

It would be much better if the standard were to define type tests such as
	is_atom(X) :- {present BSI atom(X)}.
	...
and explicitly assign NO interpretation to atom/1 or the rest.  Then
atom/1 can be defined as
	atom(X) :- fail_if(var(X)), is_atom(X).

I'm afraid that if Chris Moss has given us the right explanation, he
has thoroughly vindicated my claim that the BSI/AFNOR group are engaged
in language DESIGN ("what would it give me a thrill to MAKE this thing
do") not language STANDARDISATION ("what do most more-or-less compatible
existing implementations of this language actually DO").

> Since that decision there have been at least two compilers (NU from
> Melbourne and the ECRC product) which appear to have demonstrated
> that the fears were groundless.

I don't know about the ECRC product.  What's wrong with SICStus Prolog?
I have said before that if the standard were to strongly resemble NU Prolog
I would be far from displeased.  NU Prolog and SICStus Prolog show that you
can add coroutining without breaking anything.

> >One thing that bothers me about the BSI substandard is that there are a
> >number of serious portability problems which have simply never been raised.
> >If the committee were so much as to issue a document explaining one of these
> >issues and saying why they haven't resolved it, that would materially
> >increase their credibility in my eyes.  
> 
> I really don't think these sort of comments help. They are
> tantalising, sure. But just having you say "I know something you
> don't" doesn't help me. Am I supposed to try and outguess you?  Do I
> get marked down when I don't respond? Maybe we have thought about
> them. I don't know and am not going to go grubbing through Quintus
> manuals to find out.

(1) Too right you get marked down.  That's my objection:  the BSI/AFNOR
    group in general is having a great time indulging in the "secret vice"
    of language design and seems to be ignoring practical concerns.

(2) If the committee has thought of the points I have in mind, they have
    a duty to minute their discussion of those points.  I have to conclude
    either that they have failed to consider these practical points (nothing
    deep; I'm talking about things which really force themselves on your
    attention if you start trying to write code portable to different
    operating systems) or else that they have considered them but have
    failed to minute them.  In neither case does the committee look good.

(3) Quintus manuals have little to do with it.  Let me re-mention two of
    the portability concerns I had in mind:
    #### ###### (not in Quintus Prolog, but Prolog-# has it)
    ####-##### (not in Quintus Prolog, but Common Lisp does it)

Ok, I'm being tantalising about it.  I am sufficiently ####ed off with
the BSI/AFNOR/ISO exercise to be holding these things in reserve, but
I'm just co-operative enough to give an advance warning that there are
serious portability concerns which the current fragments utterly fail
to address and are not hinted at in any of the piece of paper I've had
so far.  This is meant as a *challenge* to the committee:  shape up!
Start thinking about the Prolog *users*!

On that topic, in an earlier posting which I mean to reply to tomorrow,
Chris Moss said
	Part of the problem in the BSI committee is probably that very few of
	the actual committee regularly used an Edinburgh Prolog. To name a
	few used by the active members, there were microProlog, Salford
	Prolog, Poplog, ESI Prolog 1 & 2, ICL Prolog, VM Prolog and more recently
	CRISS Prolog, Prolog II, BIM Prolog, ZYX Prolog. Very few of these
	are in the "Edinburgh family".

micro-PROLOG *claims* to have a DEC-10 compatible interface.
(LPA MacProlog offers a far closer approximation to "Edinburgh" Prolog
than the BSI does.)

PopLog was, in 1984, very closely DEC-10 compatible (plus extra goodies).

ESI Prolog 1 is in some sense a lineal descendant of NU 7 Prolog for
the PDP-11, written by Chris Mellish, and described in Clocksin & Mellish.
ESI Prolog 2 is still an "Edinburgh" Prolog.  (I refrain from
criticising its differences from, say, Arity Prolog, solely to avoid
giving offence.)

ICL Prolog is (or was) Prolog-X, done by Bill Clocksin, which was very
closely compatible with C Prolog.  Prolog-X and NIP (the new Edinburgh
Prolog) share a great many ideas, although NIP was a conscious departure
from ZIP (the Prolog-X virtual machine).

BIM Prolog claims to have an "Edinburgh"-compatible interface;
porting CHAT-80 to it was more pain than it really needed to be,
but nothing fundamental was involved.

ZYX Prolog (at least on Hewlett-Packard machines) comes with two
components:
	Z-Prolog (lisp-like, compatible with nothing else)
	Q-Prolog (claimed to be Quintus-compatible; from the manual
		  it does a fair job except for compile/1).

VM Prolog is not compatible with anything, so if the standard isn't
compatible with it that doesn't make life any harder for anyone.

It's a long time since I saw a Salford Prolog manual; surely the name
is Salford Lisp/Prolog, or has the Lisp component been dropped?

CRISS Prolog I've never heard of before.

So, Chris Moss named 11 Prolog implementations and said that 'very few of
these are in the "Edinburgh family"'.  From my knowledge of some of them,
6 of them claim to offer "Edinburgh" or "Clocksin & Mellish" compatibility,
at least as an option.  This relieves me, because if it were really true 
that
	"very few of the actual committee regularly used an Edinburgh Prolog"
that would utterly destroy the committee's pretensions to good faith.
It would be outrageous for anyone working on a standard for C or Pascal
to be unfamiliar with the language they claimed to be basing their standard
on, and I do not see why Prolog should be any different.  (Common Lisp and
ADA were frankly attempts to produce _new_ languages.)