Ok, I'll respond to a couple of points, below, but I think a lot of folks are confusing some operational concepts here, and it's getting hard to un-peel them.
A container has many attributes, even if Perl won't let us control them. Those include: 1. Storage 2. Conversion of the whole container to another type 3. Type assigned to keys (array: int, hash: scalar) 3.5 Type used to compare/order keys (array: int, hash: string) 4. Type assigned to values 5. Value which keys default to 6. Value which values default to 7. Behavior on normal instantiation (@a=(1,2,3)) 8. Behavior on sparse instantiation (@a[2]=3) 9. Behavior on lazy instantiation (@a=(1..Inf)) 10. How other types are converted on input 11. Syntax for indexing 12. Syntax for listifying 13. Syntax for holistic container access 14. Methods available 3 and 4 vs 5 and 6 are an interesting thing to get your brain around. When you talk about an array having a default value, I don't think of that as controlling 1..5, 7 or 10..14. I do see it having an effect on 6 and possibly an effect on 8 and 9 depending on implementation. That is to say that C<@a[10] = $mumble> shouldn't care about the default value for that array. I'm not defaulting it. If the default TYPE for that array doesn't handle the value that I'm trying to store, then type conversion comes into play, and as someone pointed out and undef might become 0 for arrays of ints. But if the default value for my array of ints is 100, then why on earth would assigning it undef result in 100 and not 0?! I could see defining an atomic type which has an alternate conversion for an undefined value. So, for example, you might have an alternate type of int that converts undef to 100. Then, of course, assigning undef to an element of an array of such values should give you 100, AND assigning undef to an element of an array of such values that defaults to 200 should still yield 100! Now again, we have to ask how much of this Perl is going to let us do. I have no idea, and don't want to suggest one way or the other. But, to mash them together into one operation restricts future expansion far too much. On Wed, 2003-01-29 at 10:32, Mark J. Reed wrote: > 1. Ordering. The elements of an array have a defined order. The elements > of a hash do not. I mentioned storage. Unless your container semantics demand a sort before searching or listing, the underlying storage impacts ordering. Elements of a has ARE ordered, just not the way you may expect. > 2. Contents. Arrays are a collection of values. Hashes are a collection > of key/value associations. The indices in an array are just a by-product > of the above fact that the values are ordered; there is no intrinsic > association between, say, the number 1 and the second element. Arrays are a collection of key/value pairs, where the key is stored by virtue of positioning in order to save space and increase access time. Don't start thinking that that information is lost! Of course there's an association between 1 and the second element. What you meant to say is that there's no storage allocated to the number 1, because we can infer the key's value based on position. > 4. delete. No reason you can't remove an element from an array, > but it's effectively a splice - the later elements move > down. I disagree. This would un-exists an item, and leave it in a state that would require auto-vivification if it were accessed in future. > 5. exists. exists(a[i]) ::== 0 <= i < a.length This is a mistake, since you're going to end up claiming that something exists when it literally does not. > Now let's look at array operators on hashes. > > 1. push. As long as the argument is a Pair, I guess this > makes sense. h.push( k => v ) ::= h{k} = v Well, the argument would be a list of Pairs, actually. > 2. pop. Problem: no ordering. There is no "last" value. > which one should this remove? There is no problem. It will pop the Pair that would be last if you converted to a list. That might be massively expensive to determine, but as long as the documentation warns the same way it does for converting to a list, then you're not causing any new problems. You keep asserting that there's no ordering to Hashes, but that's not true. I don't blame you, even the Perl docs get it wrong sometimes. >From the P5 docs: perldata: "Hashes are unordered collections of scalar values indexed by their associated string key." perlfunc/keys: "order is subject to change in future versions of perl, but it is guaranteed to be the same order as either the "values" or "each" function produces" So, they're not "unordered". They just have an ordering that you can't rely on if you change their contents. So, I would expect that: (@a=%b)[0].key eq (shift %b).key wouldn't you? That is assuming that C<@a=%b> assigns into C<@a> a list of pairs, not the expanded form that Perl5 assigns, but my point holds either way, just not the example. > 3. shift. ditto. No problem here. In fact, it's almost always a cheap operation too. Sometimes (e.g. for some types of external data) it will be expensive, but see above. > 4. unshift. identical to push. > > My point boils down to this: the semantics are fundamentally different no > matter how similar or different the syntax is. Only if you want them to be. -- Aaron Sherman <[EMAIL PROTECTED]> This message (c) 2003 by Aaron Sherman, and granted to the Public Domain in 2023. Fight the DMCA and copyright extension!