Re: A Logical Model for Lists as Relations

Jay Dee wrote:
> >>I think not. Relations are sets, lists aren't.
> >
> > Of course lists are sets plus the 'cons' operation.
>
> I suspect we're stumbling into differing conventional definitions
> rather than fundamental differences. In my mind, a list may
> hold duplicates, while a set may not. [More follows.] Too, my
> reading of MS's post led me to think position in the list was
> significant.
>
> Maybe that's covered in your theory of lists -- plus the 'cons'
> operation -- but not in mine.

What 'theory of lists' do you have in mind ? Lists are a simple recursive data type defined by something like this:

data List a = Nil | Cons a (List a)

Naturals can also be considered a similar recursive data structure defined by:

data Nat = Zero | Succ Nat

> See, I probably grok a successor operator, maybe a nil operator, but
> I'm not tracking cons and am not sure why zero and nil differ.

You do not know what the difference between the number zero and the empty list (Nil) is ?

>
> >>For lists, you need bunch theory, not set theory.
> >
> > What's 'bunch theory' ?
>
> We speak of "SQL bags" without really defining them; based on what
> experience has taught us, we think we know what's in a bag.

There are plenty of various bag formalisms, including "SQL bags". Google is your friend.

>However,
> there is a formal description of bag-like things I know as bunches.
>
> Bunch theory is one of a progression of consistent theories --
> boolean, number, character, bunch, set, string, function, program --
> that I thought might provide some useful insight into what MS was
> after.
>
> It's formal - unlike bags - and has all the benefits that accrue.
> I'll try to track down a link...

Please do.

>
Received on Thu May 11 2006 - 19:04:08 CEST