What is a type error?

[Joachim Durchholz]

Marshall schrieb:
> 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.

Sure.
It's just that I know that it's viable to give up destructive updates. 
Giving up pointers is a far more massive restriction.

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

I don't know any.
In some cases, you need an additional level of conceptual indirection - 
instead of *doing* the updates, you write a function that *describes* them.

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

Indeed.

In fact "modes" are a way to restrict pointer aliasing.

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

OK, then we're in agreement here.

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

Yup.
It's called "modes" in some other languages (Mercury or Clean IIRC).

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

Oh, right. SQL is an interesting case of getting all the problems of 
pointers without having them ;-)

Actually SQL has references - they are called "primary keys", but they 
are references nevertheless. (Some SQL dialects also offer synthetic 
"ID" fields that are guaranteed to remain stable over the lifetime of a 
record. Seems like SQL is imperative enough that programmers want this, 
else the SQL vendors wouldn't have added the feature...)
SQL also has updates.
The result: updates with undefined semantics. E.g. if you have a numeric 
key field, UPDATE commands that increment the key by 1 will fail or work 
depending on the (unspecified) order in which UPDATE touches the 
records. You can have even more fun with updatable views.
With a "repeatable read" isolation level, you actually return to a 
declarative view of the database: whatever you do with it, you won't see 
it until you commit the transaction. (As soon as you commit, the 
declarative peace is over and you better watch out that your data 
doesn't become inconsistent due to aliasing.)


Aliasing isn't really related to specific programming practices. If two 
accountants chat, and one talks about the hot blonde secretaire and the 
other about his adorable wife, you can imagine the awkwardness that 
ensues as soon as they find out they're talking about the same person!
The only thing that can really be done about it is not adding it 
artificially into a program. In those cases where aliasing is part of 
the modelled domain, you really have to carefully inspect all 
interactions and never, never, never dream about abstracting it away.


Regards,
Jo