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
