Chris Smith wrote: > Marshall <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
