What is a type error?

[Marshall]

Chris F Clark wrote:
> "Marshall" <marshall.spight at gmail.com> 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