develooper Front page | perl.perl5.porters | Postings from June 2012

Re: Smartmatch two cents (was... List::Util... when...)

Thread Previous | Thread Next
Aaron Priven
June 29, 2012 14:05
Re: Smartmatch two cents (was... List::Util... when...)
Message ID:
On Fri, Jun 29, 2012 at 12:15 PM, Klaus <> wrote:

> On 29 juin, 12:54, (Ed Avis) wrote:
> > Father Chrysostomos via RT <perlbug-followup <at>> writes:
> > I would gladly remove smartmatch from my code if Perl provided an 'in'
> keyword
> > to replace it, which is the only thing I use smartmatch for anyway.
> I agree with your statement, but the problem is that there is always
> something to be added, for example: what about numeric values ? --> so
> it seems reasonable to add an '==' comparison for numeric values, but
> hey, we also want text that looks like a number to be treated like a
> number, so we add '==' comparison for that, too, and so on...

Isn't "text that looks like a number" the whole point of distinguishing
between eq and == ? That's really the same thing.

> we finally arrive at the same mess with 'in' as we already have
> with ~~.

> Maybe two versions of 'in' might be in order, 'in_eq' for text
> comparison and in_== for numeric comparison. But again, there is
> probably a better way...
> You see, it never stops.

It seems to me that the point of replacing smartmatch with "in" is to avoid
the ambiguity of smartmatch, where it's difficult to tell which of all the
different types of comparisons will be used at any one time. Father
Chrysostomos postulates an "in" that means only one thing: an is-an-element
lookup, using "eq". This is just one of the many different smartmatch
comparisons, but it avoids the problem: it removes the ambiguity.

Yes, in theory, somebody could decide that perl needed *all* the smartmatch
comparisons to be operators. Even if all of them were added -- with
alternate eq/== versions as necessary -- they wouldn't cause the problems
that smartmatch causes.

In the long run people may decide that other smartmatch comparisons may
also be useful to retain as separate operators, whether that's
in-an-element lookup using == , or the more esoteric ones like "hash keys
intersection" for %hash ~~ @array. Some will, and some won't. But at least
the ambiguity would be gone. And it's that ambiguity -- DWIMmery gone mad
-- that is most problematical.

I do think in_eq and in_== would be useful, and with when_true, when_eq,
and when_== would cover nearly all the actual uses of smartmatch in

Aaron Priven,

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About