Re: A Logical Model for Lists as Relations

vc wrote:

> Jay Dee wrote:
> 

> 
> 
> What is your point ?

"It depends on what 'others' might have meant."

>>[snip]
>>
>>
>>>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 ?
>>
>>As above, ; and [] are operators, not merely punctuation, and when
>>items are packaged, more operators can be defined.

> 
> 
> What's an 'operator' ?

Something that yields a value. Nilary booleans give false and true, the boolean prefix unary NOT gives the complement of its input, the number infix + give the sum of two operands... Like that. Operator.

One math guy I often speak with says function when I like to say operator. Some programming types like to distinguish between procedures and functions while others use the words mutators and selectors.

Go figure.

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

>>>

> 
> 
> How do you define an operator without using the notion of the set first
> ?  What is the 'operator' in your language ?

Well, that's why bunch is there -- something to build on when defining sets.

>>there is a symmetric operator
>>that turns them into bunches. The point is that there are more
>>operators available for sets
>
> And what are those operators exactly ?

powerset, union, intersection, equality comparison, sizeof, interpolation,...

>>than there are bunches -- just as
>>there are more operators available on lists than there are on
>>strings.
>
> And what are those operators ?

composition, catenation, length, equality comparison, slicing, ordering,...

>>>>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 ?
>>
>>Well, sure: once you've got sets you can have subsets and powersets
>>and intersections and union on sets rather than union on elements.

> 
> 
> The 'union on elements'  is a beast inconnu in math.

How do you describe the comma that appears in {a, b, c}? Punctuation? Is it wrong to define it as an infix union operator? As such, it is associative - {a, b} = {b, a} - and the appeal is that there's no stray ink on the page.

>>Remember Kenneth Iverson? I used his notation for quite a while --
>>still do, as a matter of fact -- and it ain't like very many other
>>things.
>
> Who's the bloke ?

Some old dude who came up with a systematic notation that greatly facilitated the full and precise description of data and algorithms. One of its great features was that, entirely within the system of notation, one could be painfully explicit or elegantly concise. In other words, one could design an abstract algorithm and decompose it to a set of instructions that could be directly transliterated to a target machine's instruction set. Received on Fri May 12 2006 - 05:52:07 CEST