MixHash working usefully - but need some clarifications

Question

This is a (slightly belated) follow up to Does Baggy add (+) work on MixHash weights? . MixHash is a great tool for Unit comparisons - since I know that my dmix => ("m"=>2,"kg"=>1,"s"=>-2).MixHash is the same for 'kg m2 per s2' and 'kg.m^2/s^2', and so on.

Here is the threefold clarity I seek:

1. I still need to coerce the result of MixHash (+) MixHash to MixHash (the default result is an immutable Mix) - is it still the intent for the result of ops on one or more MixHashen to be a MixHash?
2. The result if MixHash (+) Any sneaks in a naughty unwanted element dmix => ("m"=>2,"kg"=>1,"s"=>-2,"MixHash"=>1) - this is a bug, right. [I have patched by setting the deflation default to empty set... MixHash $.dmix is rw = ∅.MixHash;]
3. The docs https://docs.raku.org/language/setbagmix show (+) as Baggy addition, but (-) as Set Difference. When I do MixHash (-) MixHash I seem to get Baggy subtraction - which is what I want. Hopefully this is an oversight in the docs??

Let me know if I can provide code or should submit a bug report...

Inflationism

Answer 1

1. Yes, if either side of a set operator is a mutable version, then the result should also be a mutable version. If it is not, it is a bug.

2. Any is a value, albeit an undefined one. So effectively, the right hand side is acting as if it is a Any.MixHash (which is (Any=>1).MixHash). So this is not a bug. Also, alternately, you could say has %.dmix is MixHash

3. This is indeed a problem in the docs. Not really an oversight, but actually a failure to update, because in an older implementation of the set operators, that was the behaviour.

Ulrich

thank you for the quick and comprehensive response! (reports to be submitted shortly) – Inflationism