What is a type error?

[Joachim Durchholz]

Marshall schrieb:
> Joachim Durchholz wrote:
>> You can have aliasing without pointers; e.g. arrays are fully sufficient.
>> If i = j, then a [i] and a [j] are aliases of the same object.
> 
> I am having a hard time with this very broad definition of aliasing.
> Would we also say that a[1+1] and a[2] are aliases? It seems
> to me, above, that we have only a, and with only one variable
> there can be no aliasing.

a[1] is a variable, too. You can assign values to it.

Inside function foo when called as foo(a[1]), it may even be referenced 
with yet another name and updated in isolation; foo may not even know 
it's an array element. (This is sort-of true in C, and definitely true 
in languages that don't have pointer arithmetic. If you pass a[1] to a 
call-by-reference parameter in Pascal, the callee has no way to access 
the parameter as if it were an array element.)

> A further question:
> 
> given a 32 bit integer variable x, and offsets i and j (equal as in
> the above example) would you say that
> 
>    x &= (1 << i)
> and
>    x &= (1 << j)
> 
> are aliased expressions for setting a particular bit in x?

Yes.

> I am not being facetious; I am trying to understand the limits
> of your definition for aliasing.

Understood and appreciated.

>> (After I observed that, I found it no longer a surprise that array
>> optimizations are what Fortran compiler teams sink most time into. The
>> aliasing problems are *exactly* the same as those with pointers in C -
>> though in practice, the Fortranistas have the advantage that the
>> compiler will usually know that a [i] and b [j] cannot be aliases of
>> each other, so while they have the same problems, the solutions give the
>> Fortranistas more leverage.)
> 
> I don't understand this paragraph. On the one hand, it seems you
> are saying that C and Fortran are identically burdened with the
> troubles caused by aliasing, and then a moment later it seems
> you are saying the situation is distinctly better with Fortran.

That's exactly the situation.
Aliasing is present in both language, but in Fortran, the guarantee that 
two names aren't aliased are easier to come by.
Even more non-aliasing guarantees exist if the language has a more 
expressive type system. In most cases, if you know that two expressions 
have different types, you can infer that they cannot be aliases.

Of course, the life of compiler writers if of less importance to us; I 
added them only because the reports of Fortran compilers having aliasing 
problems due to array indexes made me aware that pointers aren't the 
only source of aliasing. That was quite a surprise to me then.

> Now with this, it appears you are agreeing that SQL has an advantage
> vis-a-vis aliasing compared to OO languages. Yes?

Sure.
I think that making an aliasing bug in SQL is just as easy as in any 
pointer-ridden language, but transactions and constraints (plus the 
considerably smaller typical size of SQL code) make it far easier to 
diagnose any such bugs.

> If so, we are agreeing on the part I care about, and the specifics of
> just what we call aliasing are not so important to me.

I'm not sure whether I'm getting the same mileage out of this, but the 
relevance of a problem is obviously a function on what one is doing on a 
day-to-day basis, so I can readily agree with that :-)

Regards,
Jo