OKeefe.R.A.%EDXA@sri-unix.UUCP (11/01/83)
From: Richard HPS (on ERCC DEC-10) <OKeefe.R.A. at EDXA>
I'm afraid there is a problem with our mailing-list distribution
program, so I have missed some issues of the Prolog Digest. That is
why I am replying to Steve Hardy's points only now. He first says
Recently, I read of a new implementation of Prolog. It had an
exciting new lazy evaluation mode. It could outperform DEC-10
Prolog. What is more, it had access to all sorts of good things
like screen editors and windows.
Except for outperforming DEC-10 Prolog, this sounds a lot like
LM-Prolog. Give me a Lisp Machine, and I'll order a copy of
LM-Prolog that day. Go on, I dare you: give me a Lisp Machine !
Unfortunately, its definition of Bagof was ``wrong'', that is
didn't agree with the definition of Bagof on the DEC-20.
LM-Prolog has a primitive called "collect" which is more powerful
than bagof. Its implementor has been fair to others (by not calling
it bagof, which it isn't) and himself (it's better). I don't want
to criticise any Prolog implementor's work, not even Micro-Prolog.
My cry is "Down with Humpty-Dumpty!", that's all.
Actually, this doesn't bother me since I think DEC-20 Prolog
has it wrong. As Richard says, it depends on what one thinks
should happen to calls like:
?- bagof(X, likes(X, Y), LIKERS).
Should LIKERS be the bag of all Xs that like anything or should
it be the bag of all Xs that like the same thing with failure
generating a new set ?
The interpretation I prefer is the first; it should be the set
of all Xs who like anything.
I understand how others may disagree with my preference. I don't
understand how one could think one interpretation `objectively'
right and the other wrong.
There is just a little Edinburgh imperialism underlying
Richard's messages !
But bagof satisfies BOTH groups. I can get the set of all Xs who
like the same Y by writing the question as it stands, and he can
get the set of people who like anything by writing Y^likes(X,Y).
My objectivity in claiming that bagof is more powerful than findall
is beyond dispute. Since Steve Hardy seems to regard asserting
someone else's prior claim to a name "imperialistic", perhaps I
will be allowed to start a company and call it Teknowledge ?
His postscript says
it is a mistake to have Assert/Retract modify the behaviour
of currently active procedure calls. That's why the Newpay
example is so hard in DEC-10 Prolog. The solution is to
change DEC-10 Prolog.
As a matter of fact, it isn't the reason, but I am only too happy
to agree that modifying running code is a Bad Thing. Saying that
the solution is to change DEC-10 Prolog doesn't help. That was
the point of my original message, after all. The question is,
what do we change it TO ? What definition of assert and retract
does Steve Hardy have in mind that will be trouble free ? I would
be delighted to adopt any real solution that I can understand fully.
His next message says
I disagree with the proposal that built-in predicates should
emulate tables of assertions.
So he does, but on the grounds of type-checking. But there is a
Prolog type checker in {SU-SCORE}PS:<Prolog>TYPECH.PL, its
startup file is PROLOG.TYP. If Steve Hardy wants
succ(foo, X)
to give an error message, the answer is to pass his program
through the type checker, complete with type declaration
:- pred succ(integer, integer).
The best way to deal with errors of the succ(foo,X) sort is to
prove at compile-time that they can't happen. I do not claim that
the Mycroft and O'Keefe (mostly Mycroft) type checker is the last
word in Prolog type checking. That would be absurd. I know of at
least three improvements that could be made to it on its own, and
it should be properly integrated with the cross-referencers. But
at least it exists and is easily obtained.
That message ends by saying
Crucially, we have to decide whether Prolog is a practical
programming language (and so subject to occasional compromises)
or a concept too pure to be sullied by practical considerations.
The ``principal''(sic) by which implementors make decisions
should be ``what helps the user''.
We are in total agreement on the second paragraph. The difference
is that I am a humble programmer (in Dijkstra's sense). I know
that unless a language is very simple and very clean, I cannot use
it reliably. Show me an InterLisp manual and I turn pale. Show
me an Ada manual and I join the CND. "Keep it simple" is a very
practical request. Where DO people get the idea that programming
is done by Masters? I worked briefly in a successful software
house where most of the programmers were really struggling with
Pascal. I repeat, that was a *successful* software house.
His third message contains a masterpiece of misquotation.
A recent message on the use of Assert seemed to imply that it,
and Retract, shouldn;t be used because neither is well
implemented on the DEC-10 and both are, in fact, quite hard to
implement.
In fact assert and retract on the DEC-10 are within a factor of 3
(my guesstimate based on looking at the code and thinking about
assembly-language versions) of being as efficient as it is possible
for them to be. They are in general very easy to implement, and I
don't know of a Prolog that lacks them. What I claimed is that
1. We do not had a specification of what they SHOULD do, so
we cannot tell whether or not any implementation is correct.
2. The implementations in DEC-10 Prolog and C-Prolog (which, I
repeat, are reasonably efficient) are fairly surprise-free,
having been changed until ther results stopped being
surprising to experts, but the details are still difficult
to explain.
3. The existence of assert and retract has implications for other
parts of a Prolog system. A Prolog program which makes no use
of them will run slower in a system which supports data base
hacking than in one which does not, but is otherwise similar.
(Assuming the second system has made certain optimisations
blocked by assert and retract.)
4. We could go ahead and do the optimisations anyway. There is
essentially 0 implementation difficulty in doing this. The
trouble is that the result is almost impossible to explain.
Also, would it be correct (see 1) ?
He further says
Although Assert is`not very logical',it can be extremely useful.
True.
Without Assert one could not implement SetOf.
False.
There was a message in this Digest about POPLOG. Sent by Steve
Hardy. PopLog has setof. Does it use the database? No ! There
is also a findall (called fast_bagof) which similarly doesn't
use the data base. Neither of them is of course implemented in
Prolog, but then neither is assert.
Without SetOf all kinds of things (such as making use of a
closed world assumption) are hard.
True.
But (a) setof is my example (an operation with a clear definition
which can be implemented more efficiently without using the data
base), and (b) even with setof you can't make use of a closed
world assumption: finite failure (any instance of the Generator
which is not returned in the set is finitely failed) is strictly
weaker than the closed world assumption. (See John Lloyd's paper
"Foundations of Logic programming".) If anyone has a Prolog which
really uses the CWA, please tell this newsgroup AT ONCE, so we
can elect you to the pantheon.
Crucially, Prolog now has several classes of user. Some are
concerned with its purity and logical roots; others are
concerned with getting fast performance out of Prolog on
Von Neumann machines; others are concerned with using Prolog
to solve some problem.
Why should the last group be bothered by the concerns of the
first two ?
I think "non Von Neumann" was meant in the second class, assert
and retract are especially nasty on parallel machines, while we
can cope most of the time on serial machines. Of course the
last group should not be bothered by the concerns of the other
groups, provided, that is, that they are happy with
slow
buggy
programs and programming environments with no tools other than
editors, tracers, and buggy cross-referencers. Whence comes
this idea that Real Programmers need trash and only LongHaired
Pinkos want to understand things ? Why is it not considered
"practical" to want to have the best possible programming tools ?
Please recall that my original request was for descriptions of
useful operations which are *currently* implemented using the
data base, but which have a clear description of their own,
and which might be implemented another way. So far we have
setof and bagof -- David Warren
update -- me
assuming -- me (not doable with assert/retract)
copy -- me
queues -- Fernando Pereira
global variables -- folklore
Let's Have Some More !
Re: global variables: a new version of <Prolog>FlagRo.Pl will be
crossing the Atlantic soon.
I shall now go and try for the Nth time to read "Automated
Theorem Proving" by Wolfgang Bibel, turning for relief to "A
Discipline of Programming".