ok@quintus.UUCP (Richard A. O'Keefe) (02/14/88)
Last week, one of the people here at Quintus told me about a
new Prolog book. He had looked through it, and said it looked
pretty good. So I bought a copy. I have grown so used to
finding Prolog books horrible that this thing has been sitting
around for a couple of days waiting for me to work up the
courage to read it. Finally I decided "well, it has an appendix
about Turbo Prolog, and I don't mind one little bit about bad
Turbo Prolog books, why not start with that?"
What a pleasant surprise! I found that a 24-page appendix in a
book mainly devoted to real Prolog was better organised *and
more informative* than either of the two Turbo Prolog books I
had sought answers in.
Another good thing I can say about the book is that there are
lots of references, and they seem pretty up-to-date. (For example,
Pereira&Shieber is cited.) Sometimes the references are *too*
up-to-date: they say that "[logic programming] was first promoted
by Kowalski" and cite two 1979 publications. Off-hand, I can recall
at least one paper of his on the subject from 1974, and "Q systems"
existed before that.
Two bad things about the book.
1. There are a lot uuuuof nice things I could say about their layout
style, things which are independent of programming language. But
there isn't a lot I can praise about they way they use Prolog as
such. While I am gradually coming to dislike so-called
"quick"-sort, even it does not deserve to be written in the form
quicksort([X|Tail], Result) :-
!,
...
quicksort([], []).
They do that sort of thing again and again (look at page 199, for
example) and it is so distressing. The Clocksin & Mellish rule "put
base cases first" is an excellent one. I used to write code pretty
much like the code in this book, which was stupid of me. Clocksin &
Mellish taught me better. The half-dozen examples in this book that
I have checked have far too many cuts. For example, the pattern
clause_head :- !,
clause_body.
where this is the *only* clause for its predicate, occurs several
times in their example programs. Mind you, I've found some
pointless cuts in C&M too, and I've spent a non- trivial amount of
time stripping cuts out of my old code. (Which is why I would
rather new Prolog programmers weren't taught to over-use cuts.)
2. I have noticed two statements about Quintus Prolog so far, and
both are wrong. They say on page 407, talking about grammar rules,
that "Other Prologs, including Quintus, do not insist on exact
equivalence [between sentence --> n, v.
and sentence(S0,S) :- n(S0,S1), v(S1,s)]
and do not recognise 'sentence' as a predicate. (This enables them to
implement parsing with data structures more efficient than ordinary
Prolog clauses and lists.)" In fact Quintus Prolog *does* produce
this equivalence, as a quick test using consult(user) and listing
would have shown, and the manual says this explicitly and at length.
Furthermore, Quintus Prolog *does* use lists, as again the manual
clearly states. I don't know what the "more efficient data structures"
are; I only wish I did.
They say on page 191 that "The most efficient way to sort a list is
usually to call a built-in machine-language routine that can
perform an array-based sort on Prolog list elements without doing
any consing. Such a routine is provided in Quintus Prolog, ..."
Yes, Quintus Prolog *does* provide sort/2 and keysort/2, but *no*
they are not in machine language (they're in Prolog), they are not
array-based, and they don't avoid consing.
A mixed point.
In talking about sorting, they describe insertion sort, tree-sort,
and several flavours of so-called "quick" sort. Unfortunately,
they do not describe merge-sort, which beats "quick" sort handsomely.
That's the bad side. But the good side is that they actually took
the trouble to *measure* the sorting routines they describe, under
various conditions, and include the table of results in the book.
I'm rather impressed by that.
How do they do on the TouchStone?
Unfortunately, the code they present for findall/3 has the same
old bug found in the Clocksin & Mellish version. (In fact, it
*is* the Clocksin & Mellish version, with cosmetic changes.)
But at least they explicitly consider the possibility of
nested calls to findall/3, and point out that the first argument
need not be a variable. Their description of setof/3 and bagof/3
is ok as far as it goes, but it doesn't go very far.
Overall, though, it's pretty good. If you are just starting with
Prolog, this would be a good choice. Let me give you an analogy:
Vulcan was a cripple, but he was a son of Jupiter nevertheless.
The book is
Prolog Programming in Depth,
by Covington, Nute, and Vellino.
Scott, Foresman & Co, 1988
ISBN 0-673-18659-8
US$ 24.95ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (10/29/90)
About 10 minutes ago I inspected my departmental letter-box, and found therein a copy of a new book: Prolog: a Logical Approach Tony Dodd Oxford Science Publications 1990 ISBN 0-19-853821-9 (556 pages) I haven't had a chance to do more than skim it yet. However, what I have seen looks *good*. I'll report more fully when I've read through it properly. Sorry, I don't know the price. -- The problem about real life is that moving one's knight to QB3 may always be replied to with a lob across the net. --Alasdair Macintyre.