Re: A Logical Model for Lists as Relations

Jay Dee wrote:
> vc wrote:

[...]
> > data Nat = Zero | Succ Nat
>
> Others might write `0, nat+1: nat'

It depends on what 'others' might have meant. If they had in mind initial algebra mumbo-jumbo, they would have been wrong. The 'others' should have rather written [zero, succ]: 1 + nat ->nat. But the initial algebra mumbo-jumbo hardly belongs here, being just a variation on the Peano theme in the case of naturals.

>
> >>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 am aware of the difference between the number zero and an empty list.
> Or set. Or bag. I was not aware that you attached the name Nil to
> such. And my notation would use brackets, not parentheses.
>
> From reading the other responses to this post, I can see that
> we're stumbling all over each other's terminology.

I'll humbly follow the elders advice about not touching the Cons/Nil subject.

>> What's 'bunch theory' ?
>
> As for my own: scalars are boolean, numbers, and characters. Data
> may be structured (Here we go down the rabbit hole!) as:
> a bunch (unpackaged and unindexed),
> a set (packaged and unindexed),
> a string (unpackaged and indexed), and
> a list (packaged and indexed).
>
> More terminology? Well, bunches and sets consist of elements, which
> has the meaning we're familiar with from sets. Sets are sets; they
> are a package of elements constructed with {} operator. , (comma)
> is the set union operator. Unpackaging a set - interpolating the
> contents of a set - yields a bunch, which also has a comma union
> operator. So
> a, b, c is a bunch
> {a, b, c} is a set.

I am sorry but the 'bunch' vs. set juxtaposition just does not make any obvious sense. As soon as you talk about a 'bunch', 'herd', 'pack' of 'set', the intuition is the same: a collection of some elements. It's not important whether or not you use the pretty curly brackets.

>
> The empty bunch is null and the empty set is {null}.

See above. As soon as you imagine an empty collection, it does not matter how you label it. Besides, {null} is not an empty set, {} is, in the traditional math at least.

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

So what's the difference between the traditional list and the 'string' you've just described ?

> 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

Ah, ok. So there is no difference except the superfluos brackets ?

> 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].

When you explain the substantial, not notational, difference between 'bunches' and sets, we'll talk about the rest of the crowd, deal ?

> RM has its own scheme: everything in RM is of type boolean, other
> scalar, tuple, or relation.

It's just too lame, sorry. A trip to the library may fix the RM misconceptions, though. Received on Fri May 12 2006 - 02:57:16 CEST