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