On Thu, Nov 30, 2006 at 09:43:40AM +0100, TSa wrote: : HaloO, : : [EMAIL PROTECTED] wrote: : > $_ $x Type of Match Implied Matching Code : > ====== ===== ===================== ============= : >+ Set Set members identical match if $_ === $x : > + Array Set array equivalent to set match if Set($_) === $x : : Isn't it better to define these in terms of Bags? I mean with : Bag a supertype of Set the dispatch should go to cases : &infix<===>:(Bag,Bag), &infix<===>:(Bag,Set), &infix<===>:(Set,Bag) : and &infix<===>:(Set,Set).
I think that most Perl programmers would rather view Sets and Bags through the Hash lens, so I think I'm going to try to avoid mentioning Sets and Bags in the smartmatching table entirely, and only differentiate KeyHash, if we differentiate anything. In this view all of Set, Bag, KeySet and KeyBag are really KeyHash, which is a Hash that is being used primarily for its keys. Set and Bag just happen to be constant values of KeySet and KeyBag that also happen to override === and .WHICH to provide value rather than object semantics. I think a consequence of this view is that (x) ops are all key-based set ops unless you explicitly make sure both sides are bags. But it's still early enough in the morning that I've not thought this through entirely... What I do know this early is that we can't turn the hardwired smartmatch table into a complete crossbar of every type combination we can think up now and in the future. For learnability we've got to keep it linear somehow. That's my main motivation for trying to smash Set and Bag into being variants of the Hash role. Larry
