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

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

Thread Previous | Thread Next
From:
Aaron Priven
Date:
July 6, 2012 10:03
Subject:
Re: Smartmatch two cents (was... List::Util... when...)
Message ID:
CAFFY53b4tRND9k1igOn9ym8dL-Rx0e+ritxnWnuS8+4KeUoZMg@mail.gmail.com
It seems reasonable to me to argue that "in" is too specific, or not
powerful enough, to bother including in Perl, compared to more flexible
constructs such as the any() provided by Perl6::Junction. I don't agree
with that, because I think "is this an element of that list" is a basic
concept that is very commonly needed, and which deserves to have an easy
and utterly clear way to write it, and I think "$x in (list)" is a lot
clearer than "$x eq any(list)". But it's certainly reasonable to think
otherwise.

But that has nothing to do with types. You wrote originally:

> We're not going to be adding an `in` operator, because it goes against the
> idea of where Perl decides what type to use.

The simple version of "in" I have discussed does no such thing. It has
exactly the same treatment of numeric and string type as all the existing
comparative operators, each of which comes in numeric and string flavors.
Yes, each of those flavors would need to be justified as useful to bother
including it in Perl. But they are entirely consistent with Perl's
treatment of types.

On Fri, Jul 6, 2012 at 5:13 AM, Ricardo Signes <perl.p5p@rjbs.manxome.org>wrote:

> The use of "eq" is the primary type issue.  If we need a numeric in, then
> now

we're talking about *two* operators to justify, each with one very specific
> use.  On the other hand, you can use any() with all sorts of comparitors
> and
> values.
>


-- 
Aaron Priven, aaron@priven.com

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About