On Sun, Nov 7, 2010 at 11:19 PM, Jon Lang <datawea...@gmail.com> wrote: > Mason Kramer wrote: >> I'd like to anticipate one objection to this - the existence of the 'hyper' >> operator/keyword. The hyper operator says, "I am taking responsibility for >> this particular code block and promising that it can execute out of order >> and concurrently". Creating a Bag instead of an Array says, "there is no >> meaning to the ordering of this group of things, ever". Basically, if I >> know at declaration time that my collection has no sense of ordering, then I >> shouldn't have to annotate every iteration of that collection as having no >> sense of ordering, which is nearly what hyper does (though, I readily admit, >> not quite, because there are unordered ways to create race conditions). > > My understanding of the hyperoperator is that its primary use is to > say "operate on the individual elments of this collection, instead of > on the collection itself". In that regard, it's just as applicable to > Bags and Sets as it is to lists. Except... > > Except that the hyperoperator assumes that the collections are > ordered. It matches the first element on the left with the first > element on the right; the second element on the left with the second > on the right; and so on. Bags and Sets don't have a useful notion of > "first", "second", etc. So what should happen if I try to apply a > hyperoperator with a Bag or Set on one side?
Well, hyperoperators work fine on Hashes, they operate on the values, paired up by key if needed. (That is, %hash>>++ doesn't care about the keys, %hash1 >>+<< %hash2 sums based on keys.) I would assume that Bag should work in the exact same way. Dunno how Set should work in this context, though. -- Solomon Foster: colo...@gmail.com HarmonyWare, Inc: http://www.harmonyware.com
