[gclist] Reference counting on the fingers of one thumb.

[Richard A. O'Keefe]

John Carter wrote:
	>The 'one-thing-one-place' paradigm is also valid in current languages.
	NO! It is trivial, almost unavoidable to end up with objects having
	many different names in most languages. I try to keep my own programs
	fairly clean, but I know I can't do it in C++.

The previous writer didn't say "valid in *MOST* current languages", but
"valid in current languages", which I took to mean "SOME current languages".

I first met this idea in the SETL papers where they talked about the
"pointer"/"value" distinction.  SETL is one of the languages that has
no *programmer-visible* sharing.  (At least one SETL implementation did
this by keeping a reference count on each object.  Just before you
modify part of an object, you check the reference count.  If it is
greater than 1, you make a copy (with reference count 1) and decrement
the reference count of the original.  I believe that the current
language SETL2 still gets the same effect; by what means I have no idea.

APL is still a "current" language.  APL also present _values_ not mutable
objects:  an array is an aggregate of _values_, not _locations_.

The statistical programming language S from AT&T (and its lookalike R from
Auckland) also presents values, not objects.  Here's an R transcript:
	> X <- c(1,2,3)	# a vector with the obvious elements
	> Y <- X	# a COPY of X
	> X[2] <- 4	# change one element of X
	> X		# display X (it has changed)
	[1] 1 4 3
	> Y		# display Y (it has NOT changed)
	[1] 1 2 3


It may be of interest that S was designed to be used by _statisticians_,
not programmers.  These are people who have no trouble with matrix
operations and recursive definitions, but boggle a bit at the idea of
"locations" and "pointers".  Ross Ihaka of the R team has written quite
feelingly of the difference between languages designed for "CS people"
and languages designed for statisticians.  Whoever APL was _designed_
for, it has some popularity amongst people who see themselves as doing
financial analysis or engineering or statistics, rather than "programming".

One of the tricky things in a language like this is that if you take
the specification literally, there is an awful lot of copying.  You can
use the SETL trick at run time to eliminate some of it, but an even
better trick is to do as much as you can at compile time.

	>How are you building efficient linked lists? Are you going
	>to pass a reference to an object as a pair of (array,index) values?
	I envisage say the archetype list namely the LISP style lists as
	follows :-

Who needs linked lists?  I mean it.  Icon "lists" are really possibly
fragmented vectors.  S "lists" are vectors too.  You can do all the high
level operations you normally want to do to "lists" even though there are
no pairs underneath.  Linked lists are a *programming technique*, not an
application domain problem.  (R is very very close to S, but R "lists"
_are_ made out of pairs.  Most R/S code can't tell the difference.