On Thu, Nov 30, 2006 at 09:43:40AM +0100, TSa wrote:
: HaloO,
:
: [EMAIL PROTECTED] wrote:
: $_ $xType of Match ImpliedMatching Code
: == = ==
: + Set Set members identicalmatch 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
