Newsgroups: comp.lang.prolog
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!conway
From: conway@munta.cs.mu.OZ.AU (Thomas Charles CONWAY)
Subject: Re: Splay trees in prolog
Message-ID: <9507714.15028@mulga.cs.mu.OZ.AU>
Sender: news@cs.mu.OZ.AU (CS-Usenet)
Organization: Computer Science, University of Melbourne, Australia
References: <3kbc22$ma2@harbinger.cc.monash.edu.au>
Date: Sat, 18 Mar 1995 03:13:27 GMT
Lines: 29

"Dr. (almost) Timothy Menzies" <timm@insect.sd.monash.edu.au> writes:

>Anyone ever implemented splay trees in Prolog? 

There is a very good reason why one wouldn't implement splay trees
in Prolog: the structures of the tree must be updated on every insertion
AND every access. A single access (or insertion) can result in a
large number of modifications to the structure of the tree. In the
absence of destructive update, this creates a large overhead in terms
of both time and memory.

Data structures like red-black trees and 2-3 trees are more appropriate
for languages without destructive update, because the number of tree
rearrangements is smaller.

Fergus Henderson did some work on discovering where data structures
were uniquely threaded, and using setarg to do destructive update.
In Mercury (the new *pure* logic language which he and I are involved
with), it is possible to give mode declarations which demand uniqueness.
Using these (which the compiler can check for correctness) the compiler
is able to use destructive update of structures, so in Mercury, it
is certainly feasable to implement splay trees, and indeed it has been
done.

Functional languages have the same problems with dynamically adjusting
data structures. Clean has linear types, which are very closely related
to Mercury's unique modes, and which address the same problem.

Thomas
