What is a type error?

[Joachim Durchholz]

Marshall schrieb:
> Joachim Durchholz wrote:
>> Marshall schrieb:
>>> I can see the lack of a formal model being an issue, but is the
>>> imperative bit really all that much of an obstacle? How hard
>>> is it really to deal with assignment? Or does the issue have
>>> more to do with pointers, aliasing, etc.?
>> Actually aliasing is *the* hard issue.
> 
> Okay, sure. Nice explanation.
> 
> But one minor point: you describe this as an issue with "imperative"
> languages. But aliasing is a problem associated with pointers,
> not with assignment.

Aliasing is not a problem if the aliased data is immutable.

 > One can have assignment, or other forms
> of destructive update, without pointers; they are not part of the
> definition of "imperative."

Sure.
You can have either of destructive updates and pointers without 
incurring aliasing problems. As soon as they are combined, there's trouble.

Functional programming languages often drop assignment entirely. (This 
is less inefficient than one would think. If everything is immutable, 
you can freely share data structures and avoid some copying, and you can 
share across abstraction barriers. In programs with mutable values, 
programmers are forced to choose the lesser evil of either copying 
entire data structures or doing a cross-abstraction analysis of who 
updates what elements of what data structure. A concrete example: the 
first thing that Windows does when accepting userland data structures 
is... to copy them; this were unnecessary if the structures were immutable.)

Some functional languages restrict assignment so that there can exist at 
most a single reference to any mutable data structure. That way, there's 
still no aliasing problems, but you can still update in place where it's 
really, really necessary.

I know of no professional language that doesn't have references of some 
kind.

Regards,
Jo