Chris F Clark wrote: > "Marshall" <[EMAIL PROTECTED]> wrote: > > In general, I feel that "records" are not the right conceptual > > level to think about. > > Unfortunately, they are the right level. Actually,the right level > might even be lower, the fields within a record, but that's moving > even farther away from the direction you wish to go. The right level > is the lowest level at which the programmer can see and manipulate > values.
But how is this not always "the bit"? > > I do not see that they have > > any identity outside of their value. We can uniquely identify > > any particular record via a key, but a table may have more > > than one key, and an update may change the values of one > > key but not another. So it is not possible in general to > > definitely and uniquely assign a mapping from each record > > of a table after an update to each record of the table before > > the update, and if you can't do that, then where > > is the record identity? > > I don't know if your point of having two keys within one table amkes a > difference. If one can uniquely identify a record, then it has > identity. The fact that there is another mapping where one may not be > able to uniquely identify the record is not necessarily relevant. The issue with two keys is that the keys may not *agree* on the mapping before vs. after the update. > > For example, we might ask in C, if we update a[i], will > > the value of b[j] change? And we can't say, because > > we don't know if there is aliasing. But in Fortran, we > > can say that it won't, because they are definitely > > different variables. > > Unfortunately, your statement about FORTRAN is not true, if a and b > are parameters to a subroutine (or members of a common block, or > equivalenced, or ...), then an update of a[i] might change b[j]. Ah, common blocks. How that takes me back! But your point is a good one; I oversimplified. > Marshall again: > > Fair enough. I could only remember three, but I was sure someone > > else could name more. :-) > > There actual are some more, but very rare, for example there was call- > by-text-string, which is sort of like call-by-name, but allows a > parameter to reach into the calling routine and mess with local > variables therein. Most of the rare ones have really terrible > semantics, and are perhaps best forgotten except to keep future > implementors from choosing them. For example, call-by-text-string is > really easy to implement in a naive interpreter that reparses each > statement at every invocation, but but it exposes the implementation > properties so blatantly that writing a different interpretor is nearly > impossible. > > If I recall correctly, there are also some call-by- methods that take > into account networks and addressing space issues--call-by-reference > doesn't work if one cannot see the thing being referenced. Of coruse, > one must then ask whether one considers "remote-procedure-call" and/or > message-passing to be the same thing as a local call. > > One last nit, Call-by-value is actually call-by-copy-in-copy-out when > generalized. > > There are some principles that one can use to organize the parameter > passing methods. However, the space is much richer than people > commonly know about (and that is actually a good thing, that most > people aren't aware of the richness, simplicity is good). Fair enough. Marshall -- http://mail.python.org/mailman/listinfo/python-list
