What is a type error?

[Andreas Rossberg]

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

Consequently, you cannot possibly get rid of aliasing issues without 
getting rid of (unrestricted) mutability. Mutability implies object 
identity implies aliasing problems.

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.

In other words, pointers are essentially just an *aspect* of mutability 
in lower-level languages. On a sufficiently high level of abstraction, 
it does not make much sense to differentiate between both concepts - 
pointers are just mutable objects holding other mutable objects 
(immutable pointer types exist, but are only interesting if you also 
have pointer arithmetics - which, however, is largely equivalent to 
arrays, i.e. not particularly relevant either).

- Andreas