On Mon, 23 Oct 2017 05:23:55 -0700, c...@zoffix.com wrote:
> Set operators are a lot less useful with mutable types, like SetHash,
> because
> even when one of the operands is a SetHash, they still return a Set,
> making
> constructs like `∖=` or `∪=` entirely unusable:
>
> my $days = SetHash.new: Date.today … Date.new: '2014-04-02';
> $days ∖= $days.grep: *.key.day-of-week > 5;
> dd $days.^name; # "Set"
> $days{Date.today}:delete; # Cannot call 'DELETE-KEY' on an immutable
> 'Set'
I don't think setty operators always returning Set, is that different from
listy operators/methods (Z, grep, map...) always returning Seq.
For example, when you write:
@foo .= grep: * %% 2;
Then the grep returns a Seq, and and its the assignment to the Array variable
which makes sure that in the end you'll have the results as an Array. (Still
the same Array, in fact, just with new contents.)
If you were to use a Scalar variable, you would get essentially the same issue
as in your quoted Set example:
$foo .= grep: * %% 2; # Oops, $foo is now an immutable Seq.
The "solution", IMO, would not be to make your quoted example work (by adding
further special cases to the return types of the setty operators or otherwise),
but rather to make the following variation of it work:
my %days is SetHash = Date.today … Date.new: '2014-04-02';
%days ∖= %days.grep: *.key.day-of-week > 5;
%days{Date.today}:delete;
...and then promote %-sigiled SetHash variables as the recommended way to store
SetHash'es.
It should be possible to make this last example work by implementing `method
STORE` for type SetHash, right?
(That it currently doesn't, may well be an oversight rather than a design
choice.)
