What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
>
> >> In some cases, you need an additional level of conceptual indirection -
> >> instead of *doing* the updates, you write a function that *describes* them.
> >
> > But then what do you do with that function?
>
> I pass it to an engine that's imperative.
>
> However, that engine doesn't need to do aliasing anymore.
>
> In other words, I'm separating mutability and aliasing, so that they
> can't combine and explode.

This would seem to be identical to what I am proposing.


>  > Let's say I have an
> > employee database. John Smith just got hired on 1/1/2006 with
> > a salary of $10,000. I need to record this fact somewhere. How
> > do I do that without variables? Current-employees is a variable.
> > Even if I have the space to keep all historical data, so I'm not
> > deleting anything, I still have to have a variable for the latest
> > version of the accumulated data. I can solve this without
> > pointers, but I can't solve it without variables.
>
> As I said elsewhere, the record has an identity even though it isn't
> explicit in SQL.

Hmmmm. What can this mean?

In general, I feel that "records" are not the right conceptual
level to think about.

In any event, I am not sure what you mean by non-explicit
identity. I would say, records in SQL have value, and their
identity is exactly their value. 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?

(The situation is even more dire when one considers that
SQL actually uses bag semantics and not set semantics.)


[...]

> > I should like to learn more about these. I have some vague
> > perception of the existence of linear logic, but not much
> > else. However, I also already have an excellent solution
> > to the pointer aliasing problem, so I'm less motivated.
>
> Pointers are just the most obvious form of aliasing. As I said
> elsewhere, there are others: array indexing, by-reference parameters, or
> even WHERE clauses in SQL statements. In fact, anything that selects an
> updatable piece of data from a collection is an alias, and incurs the
> same problems as pointers, though they may come in different disguises.

Okay. At this point, though, the term aliasing has become extremely
general. I believe "i+1+1" is an alias for "i+2" under this definition.
That is so general that I am concerned it has lost its ability to
identify problems specific to pointers.


> >> Actually SQL has references - they are called "primary keys", but they
> >> are references nevertheless.
> >
> > I strongly object; this is quite incorrect. I grant you that from the
> > 50,000 foot level they appear identical, but they are not. To
> > qualify as a reference, there need to be reference and dereference
> > operations on the reference datatype; there is no such operation
> > is SQL.
> >
> > Would you say the relational algebra has references?
>
> Yes.
>
> > Or, consider the classic prolog ancestor query. Let's say we're
> > setting up as follows
> >
> > father(bob, joe).
> > father(joe, john).
> >
> > Is "joe" a reference, here? After all, when we do the ancestor
> > query for john, we'll see his father is joe and then use that to
> > find joe's father. Keys in SQL are isomorphic to joe in the
> > above prolog.
>
> Agreed. They are both references ;-P

Again, by generalizing the term this far, I am concerned with a
loss of precision. If "joe" in the prolog is a references, then
"reference" is just a term for "data" that is being used in a
certain way. The conection with a specfic address space
has been lost in favor of the full domain of the datatype.


> >> (Some SQL dialects also offer synthetic
> >> "ID" fields that are guaranteed to remain stable over the lifetime of a
> >> record.
> >
> > Primary keys are updatable; there is nothing special about them.
>
> Right - I was wrong with identifying keys and identities. In fact the
> identity of an SQL record cannot be directly obtained (unless via those
> ID fields).
> The records still have identities. It's possible to have two WHERE
> clauses that refer to the same record, and if you update the record
> using one WHERE clause, the record returned by the other WHERE clause
> will have changed, too.

Is this any different from saying that an expression that includes
a variable will produce a different value if the variable changes?

In other words, "i+1" will return a different value if we update i.

It seems odd to me to suggest that "i+1" has identity. I can see
that i has identity, but I would say that "i+1" has only value.

But perhaps the ultimate upshoot of this thread is that my use
of terminology is nonstandard.


> >> With a "repeatable read" isolation level, you actually return to a
> >> declarative view of the database: whatever you do with it, you won't see
> >> it until you commit the transaction. (As soon as you commit, the
> >> declarative peace is over and you better watch out that your data
> >> doesn't become inconsistent due to aliasing.)
> >
> > Alas, transaction isolation levels are a performance hack.
> > I cannot defend them on any logical basis. (Aside: did you mean
> > serializable, rather than repeatable read?)
>
> Possibly. There are so many isolation levels that I have to look them up
> whenever I want to get the terminology 100% correct.

Hmmm. Is it that there are so many, or that they are simply not
part of our daily concern? It seems to me there are more different
styles of parameter passing than there are isolation levels, but
I don't usually see (competent) people (such as yourself) getting
call-by-value confused with call-by-reference.


> >> The only thing that can really be done about it is not adding it
> >> artificially into a program. In those cases where aliasing is part of
> >> the modelled domain, you really have to carefully inspect all
> >> interactions and never, never, never dream about abstracting it away.
> >
> > Yes, aliasing introduces a lot of problems. This is one reason
> > why closures make me nervous.
>
> Me too.
> On the other hand, they are so immensely useful.
> Simply don't create closures with mutable data in them. Or, to the very
> least, make sure that no aliases outside the closure exist.

Thank you for the interesting exchange.


Marshall