On Wed, 2003-01-29 at 17:12, Dan Sugalski wrote: > At 12:40 PM -0500 1/29/03, Aaron Sherman wrote: > >Elements of a has ARE ordered, just not the way you may expect. > > Just to nip this one in the bud...
The bud was back that-a-way about 3 days.... > If people start assuming that there's *any* ordering to hashes, I > promise I *will* make sure that parrot's external hash class starts > returning keys and values in random order. > Hashes have no guarantee of ordering, and perl 5 (as Nick > demonstrated) delivers on that lack of guarantee. They guarantee (as stated in the docs for keys, in the perlfunc manpage, go check it out) that keys, each and values will return the elements of the hash in the same order as each other as long as you don't modify the hash between calls. If Parrot calls rand on the sequencing of returned hash data, that's fine as long as it saves that seed until the hash is later updated.... No one has suggested, as far as I can tell, that hashes should order their values internally in any particular way. What I have suggested (and I think culture shock is a bad, but sufficient reason to say that Perl isn't going this way) is that arrays and hashes and trees and funny macaroni pictures don't need separate funky tokens to identify their naming and indexing. Indexing is easy, as far as I can tell. C<%a["fire"]> is totally non-ambiguous. C<$a["fire"]> depends on the type of reference in C<$a>. If C<$a> is undefined, then you need a default, but defaulting auto-vivification based on the type of the index seems pretty intuitive to me. PHP does something like this, though I don't think that it implements actual arrays at the lowest level, it just fakes them with hashes. Perl is ok with context, so there's less concern about having arrays and hashes behave differently. No biggie. On the naming side, I like the idea of tossing C<%>, but I'm not sure you can. C<%> and C<@> have a unique and interesting behavior that is hard to manage otherwise. That is, they determine how assignments between containers behave. The idea that C<@a=%b> and C<%a=%b> are non-ambiguous is actually rather clever, and I'm not sure how to get that cleanly without ending up in a bit of a pickle over C<@a=(@b=(%c=@d))> But, I've long since decided that we're not going to re-think those symbols because they're part of the root language, not the dialect. It would be like suggesting that regular expressions should be delimited by a function-call interface instead of matched tokens. Perl programmers just don't think that way. No matter the merits of the suggestion, it's not a debate over how it *should* be done, but rather over how it *is* done. I know I sound a little shouty, here. Sorry, it's my style. I respect you all a great deal, and that's why I think this debate was worth spending a couple of days on. Thanks all. -- 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!
