From paul@inet.co.za  Fri May 12 17:31:22 2000
Received: from exchange_rbk02.inet.co.za (exchange-rbk02.inet.co.za [196.38.91.22])
	by swi.psy.uva.nl (8.9.3/8.9.3) with ESMTP id RAA11542
	for <prolog@swi.psy.uva.nl>; Fri, 12 May 2000 17:31:19 +0200 (MET DST)
Received: from pdev.inet.co.za ([196.14.60.35]) by exchange_rbk02.inet.co.za with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id KZJM0TVH; Fri, 12 May 2000 17:32:44 +0200
Date: Fri, 12 May 2000 19:19:48 +0200 (GMT+0200)
From: Paul Sephton <paul@inet.co.za>
To: Paul Singleton <p.singleton@keele.ac.uk>
cc: prolog@swi.psy.uva.nl
Subject: Re: String Representation
In-Reply-To: <391AF7A6.E354E5AB@keele.ac.uk>
Message-ID: <Pine.LNX.3.91.1000512175307.18261C-100000@pdev.inet.co.za>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 11 May 2000, Paul Singleton wrote:

> Jan Wielemaker wrote:
> > ...
> > In general, I would not use strings very often these days.
> 
> Is there any good case for using them at all?
> 
> Should I feel guilty in making no provision for them in my Java and
> ODBC interfaces?
> 
> Do you envisage "pulling the plug" on them within a few years?

Please excuse the blatherings of an idiot, but:

As far as I can tell, there are presently four distinct ways to represent 
a "string" in SWI Prolog:
  1) as an atom- at least that one is understandable
  2) as a list of integer values
  3) as a list of single character atoms
  4) as a string type (afaik internal format).

so, atom_chars/2 converts between #1 and #3
    atom_codes/2 converts between #1 and #2
    list_to_string converts between (#2 or #3) and #4
    string/1 tests for #4 and fails for the rest

I have two uses:

1)  Using #2 or #3 for parsing external data

I have a very good case for using #2 in my implementation of a parser.  
The input to the parser is a (#2) and the output is a difference list.  
For some reason or other, the use of #3 rather than #2 breaks the parser, 
although, to all intents and purposes, these should be transparent...

2) Using #4 for space efficient data storage

My case for the use of #4 is that it goes nowhere near the atom table, 
and I never search on the information stored as such.  Were one to use 
atoms to store arbitrary data, would that not lead to degradation in 
performance?  Storing the information as a list is the alternative, and I 
have no idea of the overheads there.

Am I incorrect in my assumpton that storing all "string" type information 
as atoms would lead to a very large global atom table, and thus slow 
everything down?

Regards
Paul
_____________________________________________________________________________
Paul Sephton (paul@inet.co.za)                               INET Development
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ever wondered if jumping out of the frying pan might actually be refreshing?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

