Simon --
> > I was only involved in a small amount of 'key' discussion. FWIW, I
> > would have thought the KEY_PAIR thingee was for (array) slice ranges,
> > not multidimensional indexing...
>
> Then it's doubly mis-named, because KEY_PAIR holds a single key, not a
> pair of anything, and KEY holds a bunch of KEY_PAIRs.
Hrm. I don't know about the current state of the code, but I would
expect a "key" be one of the following (logically):
(a) A scalar, to support foo[1] and bar{splee}
(b) A list of scalars, to support foo[1,2] and bar{"splee", "quux"}
(c) A list of ranges, to support foo[1..3, 17..42]
(d) Some combination of (b) and (c), to support more general array
slicing: foo[1, 2, 42..137]
I guess I thought we were going to use a list/array of range-pairs with
the second element not present in slice-parts that aren't actually
ranges, at least as a first cut (Having all indexing pay for the pair
when only ranges use it may not fall into the Purely Good portion of
the Venn Diagram :).
Its entirely possible the keying conversation went in a different
direction after the part I remember.
Regards,
-- Gregor
____________________________________________________________________
/ Inspiration >> Innovation >> Excellence (TM) \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\____________________________________________________________________/
[[EMAIL PROTECTED]]$ ping osama.taliban.af
PING osama.taliban.af (68.69.65.68) from 20.1.9.11 : 56 bytes of data.
>From 85.83.77.67: Time to live exceeded
