🚀 go-pugleaf

In article <917@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>My position is simply that if a group claim to be developing a standard
>for "Edinburgh Prolog" (rather than LM Prolog, microPROLOG, IC Prolog,
>LogLisp, PROLOG/KR, or any of several dozen related languages all with
>_some_ merit), then that is what they should DO.  

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.

>I am shocked that Chris Moss can dismiss something that will break
>thousands of programs as a DETAIL.  (We can all agree that type testing
>predicates which fail quietly when given a variable are not good logic.
>But the BSI committee are supposed to be designing a standard for the
>language we already have, and I don't know of any "Edinburgh Prolog"
>dialect where integer(_) is an error.)

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).

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. (I may be
misinterpreting their motives. Unfortunately I doubt if anyone in
France reads USENET. I'll post this to them for a response).

Incidentally, the test "integer" in Prolog II fails silently just as
one would expect, (I have just tried our copy) so I suspect the BSI
group misinterpreted the French request or my interpretation is wrong.

So nobody was forcing the error message response if a variable was
uninstantiated on anyone. At worst it was an OPTION. I can't
personally see why anyone should want to turn it on, and I've put
that position to Tony Dodd and Roger Scowen who have been concerned
with the drafting. It will come up again.

An IMPORTANT point that I think should be discussed is whether
coroutining should be in the standard and if so in what form.
Previously it had been rejected on two grounds: 1. There were several
incompatible implementations and nobody could decide between them. 
2. There were doubts about efficiency, particularly for compiled code.

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.

So there now appears to be a classic chicken-and-egg problem. Most
people do not use coroutining because their systems don't support it.
That is because many systems are totally optimised to sequential code
and may have only heard about C&M anyway.

If one had coroutining then several predicates might well behave
differently. Prolog II has predicates "bound" and "free" to deal with
this situation. The question is then "how does one ensure upward
compatibility?" and that's a thorny one.

>
>> >I am deeply offended that Chris Moss should suggest that I am arguing
>> >for my employers rather than for what is technically good.  

Please see my reply to Jeff Dalton, and accept my apologies for
having appeared to say something which I did not intend to say.

>I gave up sending comments to the BSI committee when I was told that
>100 pages of comments was far too much for them to distribute.

But please, it wasn't the FIRST 100 pages you had submitted; or even
the second. Those were distributed! (one even at the ISO meeting).


>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.


Chris Moss.