So FWIW, I think the interface I'd like to use is one where there's nothing
special about 0 values. You can put them in and they'll stay there, and if
(+) results in an element with value 0, that stays there too. But if you
ask for the value of something which doesn't have an explicit value, you'll
get 0 instead of Any.
This seems like a valuable thing to have, even if it's not the interface of
Bag itself. (I agree that there's something strange about a Bag containing
no items yet not being empty.)
That said, in this specific case a Hash or EnumMap should be pretty okay,
except that I want non-stringy keys. I've finally discovered object hashes,
so I think I'll be able to make those work.
(In case anyone stumbles upon this while trying to get non-stringy keys:
the syntax :{} constructs a hash whose keys can be arbitrary objects, not
just strings. So :{ 1=2 }1 returns Any, because the hash contains the
number 1, not the string 1. At least that's my current understanding.)
On Sun, Mar 1, 2015 at 9:01 AM, Elizabeth Mattijsen l...@dijkmat.nl wrote:
On 01 Mar 2015, at 02:01, Darren Duncan dar...@darrenduncan.net wrote:
On 2015-02-28 3:27 PM, Elizabeth Mattijsen wrote:
An interesting thought for the non-mutable cases of Set, Bag and Mix.
For the mutable cases (SetHash, BagHash, MixHash), setting the element
to 0, is effectively deleting it.
For the non-mutable case, I guess we could argue that *if* you
specified it, it should exist as such.
Will ponder about this…
If you're going to support that alternative, it should still be easy for
one to get the behavior where the non-mutable cases don't contain elements
with a count of zero. Zeros can easily arise when doing operations like
set difference or intersection etc, and we would want consistency between
values that arise that way versus ones explicitly selected with a literal.
-- Darren Duncan
The pondering has been cleared up by TimToady:
http://irclog.perlgeek.de/perl6/2015-03-01#i_10199408
so (a=0).Bag will continue to yield ().Bag.
Liz
