Re: A Logical Model for Lists as Relations

Jay Dee wrote:
> vc wrote:
> > 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.
>
> You're making my point...

What is your point ?

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

>
> >> 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 ?
>
> In the full description there are significant differences. {} is
> an operator that constructs sets;

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

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

>than there are bunches -- just as
> there are more operators available on lists than there are on
> strings.

And what are those operators ?

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

>
> Lists provide operators for composition and modification via indices
> -- what the perl crowd likes to call slicing.

The lists ' the perl crowd' likes to slice very well might .

>
> There is more to all these -- and I'm not trying to convert anyone
> or preach my religion. The point is that there are other well-
> developed theories that use the same word to mean different things.
>

If you say so.

> 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 ? Received on Fri May 12 2006 - 05:00:43 CEST