Path: utzoo!mnetor!uunet!husc6!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.prolog
Subject: Re: Strings
Message-ID: <778@cresswell.quintus.UUCP>
Date: 16 Mar 88 09:57:19 GMT
References: <512@ecrcvax.UUCP> <768@cresswell.quintus.UUCP> <5348@utah-cs.UUCP> <5349@utah-cs.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 50

In article <5349@utah-cs.UUCP>, shebs%defun.utah.edu.uucp@utah-cs.UUCP (Stanley T. Shebs) writes:
> In article <776@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
> 
> >If you need random access into some collection, a vector-like structure
> >is going to be a really good idea.  The point is that most uses of STRINGS
> >just aren't like that.
> 
> In other words, if I use strings in the ways for which lists are a good
> representation, fine, and if I don't, then my program is going to have
> really shabby performance.
> 
The point is that there is no one implementation of the abstract data type
"sequence of character" which is best for all purposes, which is hardly a
surprise.  My claim is that the implementation which is best for most of
the tasks people claim strings are good for is lists, not packed vectors of
bytes.  Is having only one representation available a good idea?  Of course
not.  Does that mean that packed vector of byte should be provided?  Not
necessarily.  A bearable-all-round implementation of logical arrays might
be a better idea.

> But surely you're not suggesting that Prologs provide "buffers"?

No, of course not.  But NOT supporting abstraction and sticking as close
to the machine as possible is how C gets the speed it does.  Specifically,
C can handle text fast precisely because it HASN'T got a string data
type.  The point was that you can't use C or Fortran or ADA as a stick
to beat Prolog with while shouting how wonderful *strings* are.  If the
goal is, as Shebs suggested in an earlier posting, to have no dynamic
allocation costs, show me how to achieve that in an implementation of
Lisp or Icon, and then we'll talk about achieving zero dynamic
allocation in Prolog.  Don't tell me that strings are so wonderful &c &c
that Prolog should have them and use C as an example to support your
case, it doesn't.

Anybody who thinks he can find in any of my postings an argument that
data abstraction is bad or that lists are a universal cure had better
take a course in reading English.  The claims I have made about strings
in Prolog are simply that

 	For most of the things I have seen strings used for in Prolog,
	the packed vector of byte representation is clumsy to use or
	slower than the list representation and usually both, and the
	use of string operations can often be avoided entirely by the
	use of proper abstractions that express what you really want.

As an example of the latter, if you want to represent arithmetic
expressions, it is clearer, faster, and a better use of abstraction,
to use trees (such as a+b) rather than strings (such as $a+b$), and
if you use data abstraction, only the module that defines the operations
will know which representation you are using.