HaloO Darren, you wrote:
I consider the current KeyHash|KeySet|KeyBag|Set|Bag etc in Synopsis 6 to be a good solution for users of sets and bags.
They are fine as far as the definition goes. But I guess it intentionally leaves certain things unmentioned.
I do not understand the rationale to make any further changes as you have described above.
First of all I like to discuss type system matters. I'm not aiming at further changes to the synopsis but a clarification on the list.
Please clarify benefits of what you are debating to change, maybe with use case examples.
I see a dilemma concerning the subtype relation of Bag and Set. There can either be 'Set does Bag' or 'Bag does Set'. The former is the cleaner solution, the latter prioritizes Set operations for the (x) ops. The question how the Set and Bag types are related to Seq is also not fully defined. The coolest solution would be to have Bag in a module from where it supertypes Set when used. In this way you get the (x) to mean set operations unless a 'use Bag' is in scope. This supertyping approach would allow further Set supertypes like FuzzySet. But I don't know what the syntax looks like. Also combining these Set supertype modules might proof difficult. Once again 'FuzzySet does Set' could be more practical. BTW, are the KeyHash, KeySet and KeyBag container types forced into hash sigiled variables? That is my %kh is KeyHash; my %ks is KeySet; my %kb is KeyBag; Regards, TSa. --
