What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
> >
> > Good point. Perhaps I should have said "relational algebra +
> > variables with assignment." It is interesting to consider
> > assignment vs. the more restricted update operators: insert,
> > update, delete.
>
> Actually I see it the other way round: assignment is strictly less
> powerful than DML since it doesn't allow creating or destroying
> variables, while UPDATE does cover assignment to fields.

Oh, my.

Well, for all table variables T, there exists some pair of
values v and v', such that we can transition the value of
T from v to v' via assignment, but not by any single
insert, update or delete. The reverse is not true. I
would consider that a solid demonstration of which
one is more powerful. Further, it is my understanding
that your claim of row identity *depends* on the restricted
nature of DML; if the only mutator operation is assignment,
then there is definitely no record identity.


> (However, it's usually new+assignment+delete vs. INSERT+UPDATE+DELETE,
> at which point there is not much of a difference.)

I am not sure what this means. Delete can be expressed in
terms of assignment. (As can insert and update.) (Assignment
can also be expressed in terms of insert and delete.) I
don't know what "new" would be in a value-semantics, relational
world. So I would say it's assignment vs. INSERT+UPDATE+DELETE,
but perhaps I'm not understanding what you mean.

Assignment by itself is complete. Insert and delete together
are complete.


> >>>>> 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.
> >>>> No, "i+1+1" isn't an alias in itself. It's an expression - to be an
> >>>> alias, it would have to be a reference to something.
> >>>>
> >>>> However, a[i+1+1] is an alias to a[i+2]. Not that this is particularly
> >>>> important - 1+1 is replacable by 2 in every context, so this is
> >>>> essentially the same as saying "a[i+2] is an alias of a[i+2]", which is
> >>>> vacuously true.
>  >>>
> >>> To me, the SQL with the where clause is like i+2, not like a[2].
> >> I'd say WHERE is like [i+2]: neither is valid on its own, it's the
> >> "selector" part of a reference into a table.
> >
> > Is it possible you're being distracted by the syntax?
>
> I think that's very, very unlikely ;-)

Well, I just thought I'd ask. :-)


>  > WHERE is a
> > binary operation taking a relation and a filter function. I don't
> > think of filters as being like array indexing; do they appear
> > analogous to you?
>
> Yes.
>
> Filters are just like array indexing: both select a subset of variables
> from a collection.

I can't agree with this wording. A filter produces a collection
value from a collection value. I don't see how variables
enter in to it. One can filter either a collection constant or
a collection variable; if one speaks of filtering a collection
variable, on is really speaking of filtering the collection value
that the variable currently contains; filtering is not an operation
on the variable as such, the way the "address of" operator is.
Note you can't update the result of a filter.


> In SQL, you select a subset of a table, in a
> programming language, you select a subset of an array.
>
> (The SQL selection mechanism is far more flexible in the kinds of
> filtering you can apply, while array indexing allows filtering just by
> ordinal position. However, the relevant point is that both select things
> that can be updated.)

When you have been saying "select things that can be updated"
I have been assuming you meant that one can derive values
from variables, and that some other operation can update that
variable, causing the expression, if re-evaluated, to produce
a different value. However the phrase also suggests that
you mean that the *result* of the select can *itself* be
updated. Which one do you mean? (Or is there a third
possibility?)


> >> I admit that identity cannot be reliably established in SQL. The
> >> identity of a record isn't available (unless via OID extensions).
> >> However, it is there and it can have effect.
> >
> > Yes, I think I see what you mean now. This is in part a consequence
> > of the restricted update operators.
>
> I don't think so. You can update SQL records any way you want.
> The unavailability of a record identity is due to the fact that, well,
> it's unavailable in standard SQL.

I disagree. The concept of record-identity is quite tenuous, and
depends on specifics of SQL semantics. (In fact I'm not entirely
convinced it's definitely there even in SQL.) It certainly does not
hold in, say, set theory. Set elements do not have identity; they
only have value. If we have a set-semantics language that
supports set variables with assignment, we still do not have
element-identity.


Marshall