Re: More on lists and sets

David Cressey wrote:
> I think we've recently discussed lists and sets at length in the context of
> the problem domain. IMO, we can give that a rest, at least for a while.
>
> We've discussed how a set (or pizza toppings) might be stored in a list,
> for the sake of convenience, but the retrieve dand used as if it were a set.
> We've also discussed how a set of tuples, with one attribute thrown in for
> sequencing purposes, can, for all intents and purposes, be treated as if if
> were a list.
>
> I want to turn my attention to the discussion of lists and sets from the
> logical and or physical design perspective. Marshall Spight recently said
> that nearly all programming languages offer support, in one way or another,
> for lists. Support for sets in much more spotty. Marshall figures that a
> good language will have to allow for both. Without disputing that
> conjecture, I want to turn my attention to facilities that can convert
> easily beck and forth between sets and lists.

"converting easily back and forth between sets and lists" is terminology I still find slightly unnerving on this newsgroup.

But, I have seen a general consensus on here that a list is a higher order construct than a set - in that conceptually, just as with a mathematical relation, a set is a component in a list's description/definition. i.e. a list is constructed from a set of items combined with an ordering (although this obviously not an ordering in the strict mathematical sense as elements may be duplicated - I am still slightly unconvinced by this, but will be flexible for now ;)

As such I would like to see a list construct that allows "extraction" of that set component, as opposed to "conversion". This would allow an opposite facility ("inject"?) that could constrain a list to a certain domain by specifying its component set a priori (the reverse of the extraction process as it were).

I still desire a system that allows such domain constraints to be constructed and lists and other orderings layered on top. Can't I have my cake and eat it?

>
> In particular, if you look at SQL as a prototype for some future interface
> language, it's useful to look at views and cursors. A view is basically a
> named query declared in the context of the database, that can be invoked to
> play the role of a table. A cursor is a named query, declared in the
> context of a user process (program), that can be invoked to play the role
> of a list. I haven't seen cursors discussed as if they were lists, but it
> seems to make an eminent amount of sense to me.
>
> If you'll allow me to stretch the concept just a bit, it seems to me that
> you can look at both a Pascal file type, and a unix pipe as a list (of file
> elements). And a cursor seems to do the same thing. I don't know how I
> would express going the other way. That is, how to declare a list, load it
> with data as if it were a list, and then turn around and deliver it to the
> database as if it were a table. What I'd like is some kind of compromise
> between unix pipes and the concpets behind Oracle's SQL*loader. Something
> that would look like an output file, but really be a pipeline into the
> database for bulk loading in a single transaction.
>
> What do you think?
Received on Mon Mar 20 2006 - 21:37:35 CET