What is a type error?

[Chris Smith]

Marshall <marshall.spight at gmail.com> wrote:
> > What you are asking for is some subset of identity, and I've not yet
> > succeeded in understanding exactly what it is or what its limits are...
> > except that so far, it seems to have everything to do with pointers or
> > aliasing.
> 
> Perhaps it is specifically first-class identity, rather than identity
> per se.

As in: "the value of one variable can (be/refer to/depend on) the 
identity of another variable"?  I can certainly see this as as 
reasonable concept to consider.

> > I'm not yet convinced that this is any different from a language with
> > standard pointer aliasing.  If I have two tables A and B, and a foreign
> > key from A into B, then I run into the same problems with enforcing
> > constraints that I would see with a pointer model... when I update a
> > relation, I need to potentially check every other relation that contains
> > a foreign key into it, in order to ensure that its constraints are not
> > violated by that constraint.  That's the same thing that is being
> > pointed out as a negative consequence of aliasing in other languages.
> 
> No, that's not the same thing. What you are describing here is
> not an aliasing issue, but simply the consequences of allowing
> constraints to mention more than one variable.

> A foreign key constraint is a multi-variable constraint.
> Specifically, a foreign key from table A, attribute a
> to table B, attribute b is the constraint:
> 
> forall a in A, exists b in B such that a = b.
> 
> Note that two variables, A and B, are referenced in
> the constraint.

There's confusion here coming from different usages of the word 
variable.  Let us talk instead of values, and of the abstract structures 
that gives them meaning.  In both cases (invariants in a hypothetical 
imperative language, and in a relational database), the constraints make 
reference to these structures of values (relations, for example, or 
various kinds of data structures), and not to the individual values or 
objects that they contain.  In both cases, the problem is not that we 
don't know what structures to check to verify the invariant; rather, 
it's that we have to check ALL of the values in that structure.

As someone pointed out, this is to be expected in a world of mutable 
things with identity that are globally locatable.  It is simple fact 
that if I tell you "I spoke to Barbara's husband", you may need to trace 
down who Barbara's husband is before you could discover that, for 
example, maybe I actually spoke to your boss, or to your nephew's best-
friend's father.  If databases are capable of modeling these kinds of 
relationships (and of course they are), then they are as susceptible to 
"aliasing" -- in a logical sense that avoids mention of pointer -- as 
anyone else.

> I don't see any aliasing in this example either.
> 

Actually, this was probably a bad example.  Let's stick to the others 
involving relationships between tuples.

-- 
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation