Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!samsung!zaphod.mps.ohio-state.edu!mips!pacbell.com!pacbell!att!cbnewsc!lgm
From: lgm@cbnewsc.att.com (lawrence.g.mayka)
Newsgroups: comp.software-eng
Subject: Re: recap so far
Message-ID: <1990Jul4.192031.4197@cbnewsc.att.com>
Date: 4 Jul 90 19:20:31 GMT
References: <8529@jpl-devvax.JPL.NASA.GOV> <5312@stpstn.UUCP> <8581@jpl-devvax.JPL.NASA.GOV>
Organization: AT&T Bell Laboratories
Lines: 26

In article <8581@jpl-devvax.JPL.NASA.GOV> kandt@AI-Cyclops.JPL.NASA.GOV writes:
>table, and so on.  Smalltalk, Objective-C, etc. generally provide only
>one implementation of an "abstract type".  This one implementation is
>chosen because it works reasonably well for all cases, but it may not be
>optimal for a specific data set; in fact, it may be orders of magnitude
>slower than one tailored for the characteristics of the data set. 

The Table Management Facility of Symbolics Genera offers automatic
data structure selection and mutation within the interface of a
Common Lisp hash table.  That is, the physical representation of
the table - as association list, set, block array, etc. - depends
on the characteristics of the currently stored dataset (and on any
optional directives and hints supplied by the programmer).

Common Lisp itself sometimes offers multiple datatypes for similar
purposes (but with differing time/space tradeoffs) - e.g., the
representation of a set as either a list, a bit vector, or a
binary-coded integer.  The choice of datatype must usually,
however, be specified explicitly by the programmer.


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@iexist.att.com

Standard disclaimer.