Re: A Logical Model for Lists as Relations

Jay Dee wrote:

> vc wrote:
>

>> 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 ?

I strongly suggest you avoid this use of null here, because it in no way resembles the null used elsewhere in database theory.

Frankly, other than seemingly unimportant punctuation, I see no difference between your set and your bunch. Is there an operational difference?

> Strings consist of items which may be any boolean, number, character,
> non-empty bunch, or set. Strings are catenated with ; (semicolon).
> So
> 17; 42; A; 17
> is a string of length 4. Items in a string can be referred to by
> their 0-origin ordinal position. Ordering is defined as lexical and
> the < = > &c operators are defined. Indexing? You bet! Slicing?
> Of course!
>
> Lists are to strings as sets are to bunches.
> 17; 42; A; 17 is a string
> [17; 42; A; 17] is a list
> Catenation can be defined on lists:
> [A] + [B] = [A; B]
> So can mapping, composition, &c -- all it takes is definition.
>
> Empty strings and empty lists? Call 'em nil and [nil].
>
> There's really nothing in any of this that's revolutionary or
> new; everything, to some extent or another, has been made manifest
> in other disciplines/languages/notations/whatever. It's simply
> unfortunate that our language prevents us from understanding each
> other.

Perhaps if you stuck to the generally accepted language instead of inventing your own, you might have greater success at mutual comprehension.

You have described a syntactic grammar with little else, and the syntax doesn't match any I am familiar with. I am familiar with plenty. In other words, you have at best described a possible representation. How is that intended to aid mutual comprehension?

> [I was wrong when I earlier said that MS needed bunches rather than
> lists. He needs lists to represent lists and, as BB and VT pointed
> out, they are readily accommodated in RM as relations. But, you
> know, I wasn't sure what MS meant when he said "list."]
>
> RM has its own scheme: everything in RM is of type boolean, other
> scalar, tuple, or relation. That "other scalar" is where we can
> put any of the things referred to here -- as well as many things
> that haven't been mentioned.
Received on Fri May 12 2006 - 02:51:12 CEST