From ok@atlas.otago.ac.nz  Fri May 12 02:27:59 2000
Received: from atlas.otago.ac.nz (atlas.otago.ac.nz [139.80.32.250])
	by swi.psy.uva.nl (8.9.3/8.9.3) with ESMTP id CAA16971
	for <prolog@swi.psy.uva.nl>; Fri, 12 May 2000 02:27:58 +0200 (MET DST)
Received: (from ok@localhost)
	by atlas.otago.ac.nz (8.9.3/8.9.3) id MAA16503;
	Fri, 12 May 2000 12:28:03 +1200 (NZST)
Date: Fri, 12 May 2000 12:28:03 +1200 (NZST)
From: "Richard A. O'Keefe" <ok@atlas.otago.ac.nz>
Message-Id: <200005120028.MAA16503@atlas.otago.ac.nz>
To: p.singleton@keele.ac.uk, prolog@swi.psy.uva.nl
Subject: Re:  Atom (was: String) Representation

Paul Singleton wrote that SWI Prolog's good handling of atoms
	... makes them irresistible (to a heretic like me) for holding e.g.
	LONGVARCHAR values retrieved from an RDBMS.

Lists are an excellent representation for strings if you need to
lots of concatenation and don't need really fast equality tests,
and you don't need to share arbitrary substrings much.

Packed-vector-of-byte (or wchar_t) is an excellent representation
for strings if you don't need to do much concatenation, you do
need a lot of them, and your Prolog doesn't garbage collect atoms.
In a language without assignment, they are particularly useful
when you need to chop them up and share the pieces, though the GC
needs to understand this.

Atoms are any excellent representation for strings if you don't need to
do concatenation and you don't need to chop them up and and you do need
fast equality tests and "same spelling" is the right definition of "equality".

Strings (in the wide sense of _any_ representation of text as a simple
sequence of characters) are a perfect data structure when there _isn't_
any structure you need to take into account; when there is important
structure they are pretty lousy.

Accepting unstructured data from a data base and doing nothing with them
except
 - send them back to the data base
 - send them to other applications that want unstructured data strings
 - print them
 - compare them
seems like a good application for atoms to me, not in the least heretical.
It relies rather more on the capacities of the particular implementation
than I care for, but programs that hook into external applications tend to
do that anyway.

	debugger's "print" mode, when terms are displayed only to max_depth(10)
	or whatever, could very long atoms also be truncated?  OLE Objects can
	be a bit tedious as they scroll past :-)
	
Doesn't the debugger call print/1 for this?
What stops you defining portray/1 to do what you want?
This is a perfectly valid portray/1 rule:
	portray(X) :- atom(X), write(@).

