🚀 go-pugleaf

In article <420@data.UUCP>, kend@data.UUCP (Ken Dickey) writes:
> 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?}

That's an evocative statement, considering that folks on both sides of
the fence can... with some justice... claim it as their own. But let's
not add a goto war to the current pointer war...

> 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.

It should also be considered that the big projects done at Xerox during
the '70s are things like Interlisp, Smalltalk, the Star office system,
and other things that would tend to push the limits of storage
management. Not exactly typical problems, and right at the bleeding edge
of technology at the time.

> '(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;"].

[ um, that's a type mismatch. Do you mean "int *three = { 3 };"? ]

You're mixing symbols and values. three is a variable of type "pointer
to integer" containing a pointer to an integer cell containing the
value 3. In lisp:

(setq three '(3)).

> 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.

Not all languages with pointers allow arithmetic on them. And you never
need to do arithmetic on a pointer in C... it is merely convenient. This
has nothing to do with the definition of a pointer.

> By "token" (a syntax concept), I presume you mean "identifier" (a
> language concept).

No, I mean a token. An opaque object. The term is used in other contexts
than compiler design... consider its use in networking. The rest of your
paragraph is complete gibberish, I'm afraid, because it's based on a
misconception.

> >*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.

Nonsense. If a value can't be aliased assignment isn't a problem. And all
aliasing problems come down to pointers at the bottom.

What you're arguing about here isn't whether one should have pointers
at all, merely how restricted the operations on pointers should be. And
that's a horse of a different color.

I use C for pragmatic reasons. It's the only language that's powerful
enough for most of the stuff I do that's also widely available and has
a good enough standard library. You just can't *get* good Pascal, Modula,
Smalltalk, what-have-you implementations on most of the machines I have
to work with. I'm not going to claim it's even a very good langauge. But
it's there, and works, everywhere I need it to be. You want to help improve
things... write some compilers and sell them cheaply.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com