Yuval Kogman wrote:
On Wed, Jul 12, 2006 at 17:58:03 -0400, Aaron Sherman wrote:
Then ~~ is wrong in that respect, and I think we should be talking about
that, not about making === into "~~, but without invoking code when it
But it should! It's the smart match! If the rhs matches the code ref
(the code ref gets it as an argument it's a match!
That's why ~~ isn't a comparison operator, but a smart match
operator - it DWIMs *very* deeply
DWIM generally means "don't shoot me in the head for trying this", and
it can be strongly argued that C<Any ~~ Any> is almost certain to shoot
you in the head a couple of times in your P6 career if we don't fix it.
Now, I'm all for every single case that Larry put in the table for Smart
Matching in S03... EXCEPT FOR RUNTIME DISPATCH! There are only two cases
of runtime dispatch in there that you could possibly invoke: Array/Array
and Any/Any. Fix those two, and I think ~~ DWIMs safely and just as
powerfully (perhaps much more so).
My suggestion (falling back to a much simpler and less dynamic =~= for
runtime dispatch) is one way to fix them, and I think that if we DO fix
them in that manner, then no one's expectations will be violated (unless
you expected C<@a1 ~~ @a2> to be shorthand for a function vector,
dot-product-like, parallel dispatch, in which case I'm going to make the
suggestion that you quietly retire from public life and find a nice
place in the mountains. ;-)
Really, all of the magic on ~~ isn't intended for such runtime traversal
of containers. it's intended for the immediate semantic value of the
compile-time typed match, most notably in the case of given which has
more connotations to hang semantic meaning off of in English. To invoke
those special rules when recursively evaluating the "sameness" of
containers doesn't even make sense if you stop and consider why you
would do such a comparison. Why is C<$a ~~ $b> going to invoke code when
I know nothing about $a and $b at compile time? Is that useful other
than in defining an alias for ~~?