Andreas Rossberg wrote:
> Marshall wrote:
> >
> > Okay, sure. But for the problem you describe, both imperativeness
> > and the presence of pointers is each necessary but not sufficient;
> > it is the two together that causes the problem. So it strikes
> > me (again, a very minor point) as inaccurate to describe this as
> > a problem with imperative languages per se.
> >
> > [...]
> >
> > Right. To me the response to this clear: give up pointers. Imperative
> > operations are too useful to give up; indeed they are a requirement
> > for certain problems. Pointers on the other hand add nothing except
> > efficiency and a lot of confusion. They should be considered an
> > implementation technique only, hidden behind some pointerless
> > computational model.
>
> Don't get yourself distracted by the low-level notion of "pointer". The
> problem *really* is mutability and the associated notion of identity,
> which explicit pointers just exhibit on a very low level.
>
> When you have a language with mutable types (e.g. mutable arrays) then
> objects of these types have identity, which is observable through
> assignment. This is regardless of whether identity is an explicit
> concept (like it becomes with pointers and comparison of pointer values,
> i.e. addresses).
Hmmm, well, I cannot agree. You've defined away the pointers
but then slipped them back in again by assumption ("objects
of these types have identity".)
First let me say that the terminology is somewhat problematic.
For the specific issue being discussed here, pointers, identity,
and objects are all the same concept. (I agree that "pointer"
connotes a low-level construct, however.) Sometimes I think
of this issue as being one with first class variables. An object
with mutable fields is a variable, and if we have pointers or
references or any way to have two different pathways to
that object/those variables, then we run in to the aliasing problem.
However if the mutable types are not first class, then there
is no way to have the aliasing. Thus, if we do not have pointers
or objects or identity but retain mutability, there is no aliasing
problem.
> Consequently, you cannot possibly get rid of aliasing issues without
> getting rid of (unrestricted) mutability. Mutability implies object
> identity implies aliasing problems.
Mutability by itself does not imply identity. I agree that mutability
plus
identity implies aliasing problems, however.
> On the other hand, pointers are totally a futile concept without
> mutability: if everything is immutable, it is useless to distinguish
> between an object and a pointer to it.
Agreed.
> In other words, pointers are essentially just an *aspect* of mutability
> in lower-level languages.
Again, I disagree: it is posible to have mutability without
pointers/identity/objects.
Marshall
--
http://mail.python.org/mailman/listinfo/python-list
