Re: Reminder, blatant ad

I agree with some of these points and disagree with others. However, they do serve to remind that anyone who deals with the theoretical end of things must always be aware that they are simply using theory to create something useful to people in practice. As such, must always listen to what people need and want. And Marshall is correct that order is damn important in practice. How many database driven don't use the sort command to create an ordered set?

Marshall Spight wrote:
> I think a good case can be made for the basic operations on set
> being the union, intersection, difference; for relations being the
> relational algebra, and for lists being simply car, cdr, cons.
> How you would combine operations on lists and sets is an
> open question in my mind. Can natural join be applied to
> a pair of lists?

Well in the end a list is just a totally-ordered set of items and as such there is a whole mathematical field out there in 'order theory' that might be applied with Codd-esque rigour to create native support for orderings in a database. But its always important to keep the two seperate concepts distincts even if you're supporting both.

Two possibilities that I can think of - it might be possible to say that merging an unordered set and a totally-ordered set (list) might reasonably create a partially ordered set. (hence you have a general system that handles all types of ordered sets underneath the hood). Or you might just want to make everything a list as in the case of lisp (and who knows, there might be something to be said for that). I think the former probably has more potential.

Marshall Spight wrote:
> While your concerns are of course good ones, I still stongly feel that
> the lists-or-sets-but-not-both rut that the field has gotten into is
> not only a false dichotomy but a pernicious one.

Totally agree. And in fact by sorting a db-relation you are in essence creating a list given the order of its delivery back to you now has implicit meaning. So in a sense practice is already forcing support for both.

> As a programmer, I want
> both! I *insist* on both, and I don't want one implemented on top of
> the other. Nor do I want my collection handling relegated to libraries;
> collections are too fundamental not to be a direct part of the
> language.

Power to the programmer ;) However as a c++ coder I often don't distinguish between the libraries and the language. Nowadays the STL _is_ c++ (and more and more so the 3rd party boost libraries).

Jim. Received on Sun Feb 05 2006 - 03:50:16 CET