I'm honored that my letter generated so much activity, and thank you all for
your thoughtful responses. I'd like to address a few points.
> On Monday, 8. November 2010 17:20:43 Jon Lang wrote:
>> Solomon Foster wrote:
>>> 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.
>>
>> I would hope that Bags would not work the same way. If they do, then
>> you get things like:
>>
>> Bag(1, 3, 2, 1) >>+<< Bag(2, 3, 1, 2) # same as Bag(1, 1, 1, 2, 2, 2,
>> 3, 3)
With respect to Bags and » and «, the spec has something to say (somewhere in
S03): "
in fact, an upgraded scalar is the only thing that will work for an unordered
type such as a Bag:
Bag(3,8,2,9,3,8) >>->> 1; # Bag(2,7,1,8,2,7) === Bag(1,2,2,7,7,8)
"
This makes sense to me. I don't see how it could be otherwise. This code
snippet also makes it clear that » and « operate on the keys of a Bag, and not
the counts or pairs of a Bag. This also makes sense to me, since Bags ought to
act much more like their keys than either their values or an EnumMap of k,v.
Please note that my original post did not address » and «, but rather the
"hyper" keyword / adverb, as in "hyper for { ... }".
On Nov 8, 2010, at 04:25 PM, TSa (Thomas Sandlaß) wrote:
> <snip>
> I'm generally very happy with the choice of sigil for Sets and Bags
> because this is what they are: scalars as far as storage is concerned.
> More important is to have the right set of operators that automatically
> imply Bags: (1,2,3,4) (&) (2,3) === Bag(1,2,2,3,3,4).
>
> Arrays and Hashes are about storage. In the abstract the memory of a computer
> is one big array! Sets and Bags are about operations on them like the numeric
> operations are on numbers or the string operators on strings. So it is very
> important to keep the domains nicely separated by means of disjoint operators.
> This is why we have ~ for concatenation and not overloaded +.
>
> It makes of course sense to iterate a Bag. But indexing it doesn't. We are
> also not indexing into strings: "blah"[2] is not 'a'.
> <snip>
I have to disagree here. Arrays and Hashes may be about storage (I don't think
they are, though, since you can change the (storage) implemenation of an Array
or Hash via its metaclass and it can still remain an Array or Hash). But
sigils are definitely not about the storage of the underlying data. Your own
statement gives the contradiction - In actual storage in the memory of a
computer, everything is somewhere in a big array. But yet, we don't prefix
everything with an @ sigil. So clearly, sigils are about something else.
jnthn said today, in irc, that "sigils are about an interface contract."
Everyone seems to agree that they imply the Positional role (i.e., the
postcircumfix:<[]> method), and that Rakudo heavily relies on this conflation,
so I'm withdrawing the suggestion that @ means "does Iterable" instead of "does
Positional".
The most important part of the @ sigil, and the reason I preferred it over $,
is that @ "flattens" (moritz++'s word), when used in a list context such as
for @blah,
map {...}, @blah.
Having Bags flatten in list context is pretty crucial to their being "as easy
and terse to use as arrays", because flattening is fundamental to how Arrays
are used, and Bags will be used like Arrays. Luckily, however, %, which
implies the Associative contract, also flattens in list context. If Bags and
Sets are sigiled with %, they should flatten, and all that remains is to make
sure they flatten into a list of keys, and not a list of enums.
Any thoughts on that?
