[kepler-dev] Re: zero-length arrays

[Tobin Fricke]

On Thu, 12 Aug 2004, Shawn Bowers wrote:

> From the documentation, it sounds like the intersect operation is
> really just a set-based intersection over the attribute names.

Yup.

> records from sets/arrays isn't quite correct.  For example, if we could
> do set (i.e., array) based intersection, should intersect({f=1},{g=1})
> == intersect({1},{0}) be true or false.

Tricky.  It would be nice if that identity held.

Yesterday I was thinking that maybe it doesn't matter that "{}" is
ambiguous.  Could it just be the special NullArrayRecordToken, since any
'get' operations are doomed to fail anyway?  It would be annoying to
implement (especially without multiple inheritance), however, but I did
like the idea because it's sort of outrageous. (-:

It's tempting to define set operations on arrays, but that illustrates
what I meant by my comment yesterday about how the underlying
representation matters.  If we had set operations on arrays, it would be
quite convenient to use them, but arrays make somewhat poor
representations of sets.

> Since records are really just special forms of sets, the answer should
> probably be true --

I would say that a record is a 'surjection'.

> but by separating the two data types, the answer would probably be
> false.

Unless special code were added to ArrayToken.equals and RecordToken.equals
to allow equality between null arrays and null tokens.  I don't know what
bizarre effects that might have.

Tobin