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

Reply via email to