On Mon, 23 Oct 2017 09:12:58 -0700, sml...@gmail.com wrote:
> 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.)
Thanks for clarifying. Yeah, it looks better if it had a % sigil on it too.
Gonna reject this issue and open a new one on our GitHub tracker[^1] to take it
for a spin
[1] https://github.com/rakudo/rakudo/issues
