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 ~~?

Reply via email to