From: Gavin Sinclair <gsinclair@...>
Date: 2003-07-31T08:01:03+09:00
Subject: Re: Set doesn't have [] instance method - and Set#| is inconsistent with Set#&

On Thursday, July 31, 2003, 2:11:47 AM, Mark wrote:

> On Wed, Jul 30, 2003 at 04:23:27PM +0900, Brian Candler wrote:
>> On Wed, Jul 30, 2003 at 11:07:02AM +0900, Mark J. Reed wrote:
>> > It's not a lookup; it's a membership test.  Sets are not Hashes - they're
>> > Arrays that don't allow duplicate values.
>> 
>> I disagree - Arrays are ordered, Sets are not.

> True, which is why s[n] doesn't make sense for numerical indices n, either.
> I wasn't being precise; I was just trying to make the point that for
> purposes of my argument and the message to which I was replying, sets
> are more arraylike than hashlike.  They are, of course, actually a 
> third, completely different animal.

I agree, of course, so the comment below is to be taken as another
description, instead of literal definition.

> Sets are unordered collections of individual items.  There is no
> explicit or implicit mapping between these items and any other set
> of entities.

> Arrays are also collections of individual items, but the items are ordered;
> there is therefore an implicit mapping to the items from the set of
> nonnegative integers.

> Hashes are unordered collections of (key, value) pairs, which therefore
> comprise a mapping from the set of keys to the set of values.

Sets could also be considered a mapping from all objects to true or false.
Those objects which map to true are "in" the set.  Those which map to
false are not.  This implies non-duplication and unorderedness.

My point is that I don't care about data type definitions that
forcefully distinguish between keys and values.

Gavin