Re: More on lists and sets

"JOG" <jog_at_cs.nott.ac.uk> wrote in message news:1142887054.959879.130850_at_t31g2000cwb.googlegroups.com...
> 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?
>

JOG, Your response is a great improvement on my original post. I take it as a build.

You are right, that a list doesn't inherently possess the "no duplicates allowed" rule, and therefore is like a bag rather than a set. But look at it this other way: if the ordinal position in the list were taken as a data item, even if it isn't explicitly represented as data, then the elements of a list do form a set. Now this addition of a "sequence number" in order to guarantee uniqueness bears a strong resemblance to the sort of newbie question that draws a canned tirade from Joe Celko. I think there's more than coincidence at work here.

I think that, in certain contexts, we inherently think in lists. And it's not because our programming languages trained us to think that way, but because our brains are predisposed to think that way. Of course, I can't prove this. Having said that, I think sets are so very useful, in the context of sharing durable data, that if sets didn't exist, it would be necessary to invent them (nyuk, nyuk, nyuk). Received on Mon Mar 20 2006 - 23:22:35 CET