Larry Wall wrote:
> David Green wrote:
> : And if you restrict your "hash" to numeric keys, Perl could notice and
> : optimise it into an array. (Or integer keys, or positive integers, or
> : a consecutive range of positive ints....)
>
> What exactly do you mean by "could notice"? The point about the
> distinction between .[] and .{} is that it makes it very easy for the
> compiler to notice (at compile time) that .[] is going to be indexed in
> a standard fashion, so it can optimize the heck out of it.
I think that David Green was referring to the possibility that arrays that
are sparse and/or not 0-based cannot be optimized to the same extent as a
contiguous 0-based array can be, but they can _still_ be optimized to a
greater extent than a hash can be. Am I reading you right, David?
> : If we consider a generic "data structure" type (which may or may not
> : be optimised under the hood for integral indices), then why shouldn't
> : {} be the "index-by-name" interface, and [] the "index-by-ordinal"
> : interface? (Does that mean [$x] is just a shorthand for {nth($x)}?)
>
> I think you just said what I said, sort of.
In terms of the parenthetical at the end of David's statement, that would
only be true if nth(0) is the same as 1st and nth(-1) is the same as last.
But the advantage of restricting .[] to dealing with a zero-based
contiguous index is that it renders the need for C<1st, 2nd, 3rd, ...> and
C<nth()> ordinal notations moot: [0] always refers to the 1st element, [1]
always refers to the second element, [-1] always refers to the last
element, and so on. The ordinal notations could theoretically still be
kept for use in .{}, but given a choice between saying [0] and {1st} I
would pretty much always go with the former.
> : Of course, there is one important difference between arrays and
> : hashes: arrays are ordered. People do keep asking about ordered
> : hashes, though. There's no reason you couldn't use ordinals with a
> : hash anyway (the "order" may not be particularly meaningful, but
> : sometimes you don't care -- of course, in those cases you'd usually
> : iterate through it, but it could be handy to be able to say
> : %h[rand(last)] (except that isn't really quite how you'd say it, but
> : you get the idea)).
>
> I expect people would mostly want to treat the hash as an ISAM, and
> ask for the successor of the current entry without necessarily caring
> about its index.
ISAM?
> : Data structures might have default sorting by key (since that's what
> : arrays have), but you could sort other ways... maybe nth takes a "by"
> : adverb: "first"="first :by key", vs. "first :by value". Hm, it
> : probably should take a closure (along the lines of "sort").
Funny you should mention that, especially considering the (relatively)
recent discussion of revamping "sort", and noting that providing an
"ordering" for a hash would essentially be the same as providing the hash
with a "default" sorting mechanism.
=====
Jonathan "Dataweaver" Lang
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
