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