🚀 go-pugleaf

Paraphrase of Peter da Silva: "On what statistical evidence are you
bashing pointers as source language constructs?"

"Pointers are the gotos of the 90's" {I forget who said that.  Alan Kay?}

There was a study done at Xerox PARC on large project development that
showed something over half the development time was spent with storage
management issues.  I believe that the development was done in Mesa,
which is why Cedar has automatic storage management (a.k.a. garbage
collection).  I have found similar results in my development work (C,
Pascal, vs. Scheme, Actor).  "Pointers" contribute in no small way to
this problem.  In the Portable Common Runtime System work (also at
PARC), it was found that C presented hardest runtime problems because
of its low level memory model.

[Most projects I am involved in are >500K LOC]


peter@ficc.ferranti.com (Peter da Silva) writes:

>In article <3407.2720318d@cc.helsinki.fi> jpiitulainen@cc.helsinki.fi writes:

ken>> It is a pair of values.  Pointers to values, as separate from values, do
ken>> not exist.

>So, (a) is the same as a?

No, '(a) is the same as (cons 'a '()).

ken>> In Scheme, any
ken>> pair or vector can hold arbitrarily big values---even itself---pointers
ken>> are not needed and there is no such thing as a pointer to an integer.

>Really? As far as aliasing and debugging are concerned (3) is a pointer
>to 3. (well, to 3 and nil)

'(3) is the result of (cons 3 '()) or (cons '3 '()), this is not the
same as three [as defined in C as "int *three = 3;"].


ken>> Pointers (addresses) are usually used in the implementation,

>No, addresses are not what I mean by pointers. The definition of a pointer
>that I am using is "a token that can refer to any language object". The
>operative word is "any".

Ah, the heart of the issue! It would be interesting to do address
arithmetic on a token!  You are definitely going against the
literature here.  I think that you should look up th definition of
"pointer" in a few texts.

By "token" (a syntax concept), I presume you mean "identifier" (a
language concept).  It seems strange to refer to "identifier
references" as "pointers", as they have no immediate runtime
correspondence [e.g. a "variable" may be assigned to only once to a
known value and the compiler may choose to put that value in the code
rather than create a location to hold it].  If you use the term
"object reference" or "descriptor" or "handle" or just "object",
there would be much less confusion here.

It is much more interesting to think of *values*, which may (or may
not) be *named* in various places in a program than to follow all the
values which a name may denote.


?>> The same problems are there, when applicable.  Lists are just chains of
?>> pairs, or pairs who's cdr fields are pairs, and the cdr pair can be a
?>> part of some other list, too.  Thus mutation is dangerous.

>*Exactly*, just as arbitrary pointer operations are dangerous. And for
>exactly the same reasons.

N.b.: this is basically an argument against assignment, not pointers.


-Ken			kend@data.uucp