What is a type error?

Marshall marshall.spight at gmail.com
Mon Jul 17 14:31:40 EDT 2006


Chris Smith wrote:
> Marshall <marshall.spight at gmail.com> wrote:
> > We seem to have slipped back from the hypothetical relation language
> > with only assignement back to SQL.
>
> [...]
> I don't see how such a language (limited to assignment of entire
> relations) is particularly helpful to consider.

I find it useful to consider various language features together and
individually, to see how these features interact. If nothing else,
it furthers my understanding of how languages work.


> If the relations are to
> be considered opaque, then there's clearly no aliasing going on.

Not certain I understand, but I think I agree.


> However, such a language doesn't seem to solve any actual problems.  It
> appears to be nothing other than a toy language, with a fixed finite set
> of variables having only value semantics, no scope, etc.

No, such a language is entirely useful, since relational assignment
is *more* expressive than insert/update/delete. (How did you get "no
scope"
by the way? And fixed variables? All I said was to change ins/upd/del
to
assignment.)

Also note one could fairly easily write a macro for ins/upd/del if one
had assignement. (See below.)

Now, there are some significant issues with trying to produce a
performant implementation in a distributed environment with strictness.
In fact I will go so far as to say it's impossible. However on a single
machine I don't see any reason to think it would perform any worse,
(although I haven't thought about it deeply.)


> I assume that
> relational databases will have the equivalent of SQL's update statement;
> and if that's not the case, then I would need someone to explain how to
> accomplish the same goals in the new relational language; i.e. it would
> need some way of expressing transformations of relations, not just
> complete replacement of them with new relations that are assumed to
> appear out of thin air.

Consider:

i := i + 1;

Note that the new value of i didn't just appear out of thin air; it was
in fact based on the previous value of i.

Given:
variable T : relation of r;
update_fn : r -> r   // takes one record and returns new, updated
record
filter_fn : r -> boolean  // indicator function

insert(T, new_rows) => { T := T union new_rows; }

update(T, update_fn, filter_fn) => {
  transaction {
    let Tmp = filter(T, filter_fn);  // select only those rows to
update
    T := T minus Tmp;
    T := T union update_fn(Tmp);
  }
}

delete(T,filter_fn) => { T := T minus filter(T, filter_fn); }

So we can define insert, update and delete in terms of relational
assignment, relational subtraction, and relational union. Type
checking details omitted.


Marshall




More information about the Python-list mailing list