🚀 go-pugleaf

In article <7244@agate.BERKELEY.EDU>, ed298-ak@violet.berkeley.edu (Edouard Lagache) writes:
> In article <1150@kulcs.UUCP> bimbart@kulcs.UUCP (Bart Demoen) writes:
> >I have been busy with the theorem prover of R. Overbeek, which was used
> 	.
> >For destructive assignment, I implemented (in the BIMprolog kernel of
> >course) a predicate
> >	replaca/3
> 
> 	Here is an item that has interested me almost since I started using
> 	PROLOG.  Why aren't destructive list predicates a part of PROLOG?

Oh dear oh dear oh dear oh dear.  Have you ever felt that everything you
have done for the last N years has been futile?  Have you ever been
telling people about the milk and honey of the Promised Land, only to
have them turn around and say "What about leeks?  We had great leeks in
Egypt."

Let's clear up a misconception.  Demoen's rplaca/3 is NOT an operation
on lists as such, it's the equivalent of an array element update (see
'$SET' in some versions of C Prolog, setarg/[3,4] in some other Prologs).

But didn't you spot the punch-line in Bart Demoen's posting?  He did all
those things, including adding rplaca/3 , AND IT STILL DIDN'T HELP.  The
time went down from 77 seconds to 22 seconds (the last reduction was
from 44 seconds to 22 seconds).  However,

(a) the original version of the program took 26 seconds in Quintus Prolog
(b) Tim Lindholm was able to reduce that by a large factor (I haven't the
    figures to hand, but it was about a factor of 2, and did *not*
    involve the use of any sort of destructive operations).
(c) the C version took 1.18 seconds
(d) there is reason to believe that the C version could go twice as fast
(e) these times are times on one specific problem.  It's not enough
    to get close to C speed on this problem.  The method used has to
    SCALE at least as well as the C version scales.

The whole problem with Overbeek's Prolog program is that it faithfully
mirrors the structure of his C program.  The way to obtain a fast Prolog
program is to go back to the specification, and write a Prolog program,
instead of writing a C program in Prolog.

> 	So what you do say folks?  Shouldn't destructive manipulation be
> 	a part of PROLOG (or is it a part of most PROLOGs already?)

Look, if you want to use destructive operations, please use Lisp.
Lisp is GOOD at that sort of thing, though I would warn you that in
some Lisp systems rplacd is very bad for efficiency.  The whole point
of Prolog is that it is supposed to be based on logic.  Destructive
operations simply have no place in that model.  Which is not to say
that arrays with unit expected-time update do not!  There were several
papers about them, and one technique was posted to the Prolog Digest.
Is anyone out there using a Prolog with logical arrays?  What's it like?

Why are so many people chasing the "destructive operations" pennies
when there are "better data structure" POUNDS to be won?