What is a type error?

[Marshall]

Chris Smith wrote:
> 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.

Yes, I think it's important. We've become so accustomed, in
modern languages, to considering variables as first-class,
that we cannot see any more that many of the problems
attributed to variables (such as aliasing) are actually
problems only with *first-class* variables. The historical
reality that non-first-class variables are associated with
more antique languages (Fortran/pre-OO) makes us shy
away from even considering removing first-class status
from variables. But I think it's an important point in the
design space (although I certainly respect Andreas'
reluctance; to paraphrase, "first class or bust." :-) )

After all, what are the alternatives? Purely-functional
languages remove themselves from a large class of
problems that I consider important: data management.
I have explored the OO path to its bitter end and am
convinced it is not the way. So what is left? Uniqueness
types and logic programming, I suppose. I enjoy logic
programming but it doesn't seem quite right. But notice:
no pointers there! And it doesn't seem to suffer from the
lack. I really don't know enough about uniqueness types
to evaluate them. But again, I already have my proposed
solution: variables but no first-class variables. (And yes,
I'm acutely aware of how problematic that makes
closures. :-()


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

I don't think that will work. We cannot discuss constraints, nor
aliasing, without bringing variables in to the picture. (Aliasing
may exist without variables but it is a non-problem then.)


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

I am not certain what this means.


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

But not all values in all structures, as you do in the presence
of aliasing.


> 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 that they're the same thing. Similar is some ways, yes,
but not the same.

As I said much earlier, the terminology is problematic, and it may
be that we (or just I) simply lack the precision of terms necessary
for the conversation.

 
Marshall