On Fri, Sep 10, 2004 at 05:47:29PM -0600, David Green wrote: : On 2004/9/06, Larry Wall wrote: : : >Another possibility is that .[] always forces the "normal" view of an : >array as 0-based, and if you want non-0-based arrays you have to use : >the .{} interface instead, on the assumption that strange subscripts : >are more like hash keys than ranges of integers. : : That's true. But it's got me thinking about the connection between : arrays and "associative" arrays. In fact, the user doesn't need to know : that a "hash" is implemented with a hash table, and an "array" isn't; : and nothing stops you from using numbers as hash keys.
Yes, but... : 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. : 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. : (Will P6 arrays/hashes have an ".index" method to return what index they : are? Or .index for the ordinal and .key for the name. (Although .key : is perhaps a bit too close to .keys when the member is itself a hash.)) You mean individual hash/array elements knowing their key/index? I think that's a feature looking for a way to slow down the common operations. If you an array or hash element to remember its index/key, you should ask for .pairs or .kv. : 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. But a hash with a real ordering could certainly provide a .[] interface if it conforms to the usual semantics. : 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"). : : : Anyway, I'm rambling, but there's something to the idea of Perl offering : some sort of generic "data structure" type... That's what the hash interface is intended to provide. : "my $hash is Struct;" would be the most general, no restrictions on : keys, and no ordering, so Perl is free to use a hash table without : worrying about the order. : : "my $array is Struct(keytype=>PosInt, ordering=>keywise)" has keys : restricted to ints, and iterates in order by index, i.e. it's : implemented as an ordinary array (where [$n] and {$n} refer to the same : element). That's why I extended the shape trait to specify hash keys. : "Hash" and "Array" types would be shorthand for those kinds of Structs, : but you could define your own by providing suitable shapes and : orderings. (Hm, since Hashes are the most general, they're probably : actually the base type, rather than "Struct", which does sound kinda : silly, and probably sounds sillier if you're not used to C.) Yup. : I was also going to suggest an in-between type of structure, like a : Collection in VB, that accepts anything for the key (or some useful : restricted type?) but is ordered (in order of when elements were added). : But I can't think of any character available for the sigil. =) The sigil for that is %, with appropriate declaration. Larry