What is a type error?

[Marshall]

Joachim Durchholz wrote:
> 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.

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.


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

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.

I recognize that this is likely to be a controversial opinion.



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

I heartily support immutability as the default, for these and other
reasons.


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

Are we speaking of uniqueness types now? I haven't read much about
them, but it certainly seems like an intriguing concept.


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

Ah, well. I suppose I could mention prolog or mercury, but then
you used that troublesome word "professional." So I will instead
mention a language which, if one goes by number of search results
on hotjobs.com for "xxx progammer" for different value of xxx, is
more popular than Java and twice as popular as C++. It lacks
pointers (although I understand they are beginning to creep in
in the latest version of the standard.) It also posesses a quite
sophisticated set of facilities for declarative integrity constraints.
Yet for some reason it is typically ignored by language designers.

http://hotjobs.yahoo.com/jobseeker/jobsearch/search_results.html?keywords_all=sql+programmer


Marshall