Chris Smith wrote:
> Marshall <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
