On Thu, Nov 24, 2005 at 12:08:44AM +0100, Stéphane Payrard wrote:
: What about array with holes as supported by Parrot?
We have prior art with hashes, but it's not clear how well that maps
across.
: Does .elems return the number of elements with or without
: the holes?
In Perl 5, non-existing array elements are still counted in size,
but non-existing hash elements are not.
And this is actually pointing to a distinction we have to make for
hashes and arrays that we don't have to make for ^5, because the
integers 0..4 always exist, whereas the keys of a hash or array come
and go. When we speak of the domain of a hash that is declared
my %hash{Str}
we could be confusing the signature Str with the current domain of
the mutating function, %hash.keys, which is presumably some subset
of Str, since Str represents an infinite set.
Put that together with use of 5 in a signature as a type. If you declare
my num %hash{5}
you may only index %hash with values that match the signature :(5).
The long form of that declaration is
my %hash :(5 --> num);
Where I was going with S9 is that we can't afford to make
my num @array[5;5;5]
a shortcut for
my @array :(0..4, 0..4, 0..4 --> Any)
because that confuses the use of 5 as an enumerated type value with
its use as a sizer. But the sizer notation is darn convenient, so
that's where
my num @array[^5;^5;^5]
came from. Assuming
my %hash{Str} = somevalues();
note the crucial distinction between
my %newhash{%hash.sig}
and
my %newhash{%hash.keys}
The latter produces a hash that may only be indexed by the *existing*
keys of %hash.
: Does iterating over the array iterates over the holes as well?
I'd say @array.keys should leave out the holes by analogy with hashes.
Presumably [EMAIL PROTECTED] would do the same.
Earlier I said that I thought .keys should just iterate the top
dimension, but I think that's probably wrong. Likely ,kv will most
naturally alternate key tuples and values, so I think .keys is also
returning key tuples, and we need some other notation for returning
the keys of the first index. .topkeys seems stupid, but I'm working
with a migraine today, so I'm stupid too. I feel like there's an
obvious solution, but I can't see it. Sigh.
In a sad twist of fate, you can't be as brilliant as you are some
of the time all of the time. :-)
: That would sound inefficient to do that over a mostly empty array.
True 'nuff. I think Juerd's question comes down to whether [EMAIL PROTECTED]
tracks existing elements or last element. I can see arguments for
both sides. The Perl 5 bias was that you should probably use the
hash interface if you have sparse data, and [EMAIL PROTECTED] tracks last
rather than [EMAIL PROTECTED] But then the implementation of arrays
in Perl 5 was such that non-existing elements still occupy an SV*
slot, so it kind of made sense from an efficiency point of view.
But it'd be kind of nice if @array went false when the last key
disappeared from a sparse array. But maybe [EMAIL PROTECTED] doesn't always
have to mean [EMAIL PROTECTED] == 0. Seems broken if not, though.
: Related question, Is there a way to get a list of iterators
: that iterate only over the non-holey parts of an array?
Not in Perl 5. I think .keys/^ should probably do that.
Larry
