From p.singleton@keele.ac.uk Tue Feb 20 14:39:06 2001
Received: from scooby.lineone.net (doggy.lineone.net [194.75.152.224])
	by swi.psy.uva.nl (8.11.2/8.11.2) with ESMTP id f1KDd6Z05005
	for <prolog@swi.psy.uva.nl>; Tue, 20 Feb 2001 14:39:06 +0100 (MET)
Received: from keele.ac.uk (host62-6-87-173.dialup.lineone.co.uk [62.6.87.173])
	by scooby.lineone.net (8.9.3/8.9.3) with ESMTP id NAA13942;
	Tue, 20 Feb 2001 13:37:14 GMT
Message-ID: <3A9269C5.D58D5AC6@keele.ac.uk>
Date: Tue, 20 Feb 2001 12:57:41 +0000
From: Paul Singleton <p.singleton@keele.ac.uk>
Organization: SmartArts Computing Consultancy
X-Mailer: Mozilla 4.74 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Richard A. O'Keefe" <ok@atlas.otago.ac.nz>,
   SWI Prolog <prolog@swi.psy.uva.nl>
Subject: Re: [SWIPL] keysort
References: <200102192233.LAA05791@atlas.otago.ac.nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Richard A. O'Keefe" wrote:

> Assuming for the sake of argument that they represent weighted edges in
> a graph, a better representation (requiring less space to store it and
> less time to process it) would be
>         [edge(a,b,2), edge(a,c,3), edge(a,b,1),
>          edge(b,a,5), edge(d,c,4), edge(f,r,6)].
> Whatever they represent, a compound term with a well-chosen word to label
> it would be a better choice than a list.

I think there's a case for choosing a compound term to represent the arc:

          a-b

and a compound term to represent the weighted arc:

          (a-b)-2

where -/2 is -(well,chosen) if you have a library of predicates for
manipulating lists of pairs (keysort and much more), and another library
of graph operations on lists of arcs (NB this is not a great graph ADT,
but it has its uses), in each case using the functor -/2

I only mention this to illustrate a weakness of Prolog (compared to e.g.
Java) in defining new types: it doesn't support implementation inheritance,
so I cannot define a specialisation of an old type which both inherits
useful operations yet has its own identity (for polymorphism etc.).

E.g. ordsets are conventionally represented as, and indistinguishable
from, lists.

So there often seems to be a conflict between choosing a data structure
for design-time efficiency and choosing it for run-time efficiency, and
between expressing its particular semantics and compactly representing
its essential structure.

Is this inherent in a dynamically typed language?

Are there any general techniques for gettiong the best of both worlds?

Paul Singleton


