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

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

Thread Previous | Thread Next
David Mertens
July 3, 2012 06:18
Re: Smartmatch two cents (was... List::Util... when...)
Message ID:

I have a few thoughts about introducing "in" as a new infix operator.

1) Why would "$a in %hash" be equivalent to "exists $hash{$a}"? It seems
that it would be conceptually closer to (and much more useful as) "$a in
values %hash".

2) PDL defines a method called "in" and it is exported when a user has "use
PDL" in their code (i.e. it is very typically exported). The basic
convention is "in($needle, $haystack)". PDL also defines methods "any" and
"all" which returns a boolean true value if any value or all values in its
argument piddle is nonzero. These methods are typically used as

    if (any $first == $second) { ... }
    if (all $first == $second) { ... }

Because these methods are exported by default, it is quite conceivable that
users could have the following in their code:

if ( any in $needle => $haystack ) {

which would be more verbosely written as

if ( any (in ($needle => $haystack) ) ) {

Now, as you can see, we get into some murky backward compatibility issues.
As long as this is properly handled with "use feature 'in'" or some such,
then I have no qualms putting code in PDL that handles "in" differently
based on the current feature set. I'll need some pointers on how to
determine the current feature set that was requested by the user when they
import PDL's functions, but we can do that. (And, I'll need some pointers
about how to handle things if the user says "use PDL; use features 'in'",
since in that case the import mechanism will think that the user won't have
feature 'in' at import time.)

3) Continuing from #2: If a user decides to use the old form of in because
they've trained their fingers that way:

    use PDL;
    use feature qw(in say);
    my $haystack = sequence(10);
    my $needles = pdl(-1, 5, 17);
    say "Some of $needles were found in $haystack"
        if any in $needles => $haystack;

how is that parsed, and what sort of error reporting happens? I expect that
this will try to call PDL's any method without any arguments and then see
if the returned value is in $needles? If that is the case, the user will
get an error about not specifying enough arguments to the any method [1],
which would be confusing at best. Obviously there would be no way for our
"any" method to know that it's being called in the context of an "in"
statement, so we wouldn't be able to craft a more tailored error message.

4) As with all other infix operators it would be great to be able to
override the infix operator because it would allow for code like this,
which reads like English:

if (any $needle in $haystack ) {

So I like the idea in general, but I have backward compatibility concerns
in mind. do you have any specific ideas for handling these concerns?


[1] Actually, at the moment PDL doesn't even check its arguments to "any":

perl -MPDL -e 'any'
Can't call method "clump" on an undefined value at
line 1493.

Looks like I need to file (and fix) a bug, then.

On Tue, Jul 3, 2012 at 3:59 AM, Ed Avis <> wrote:

> Just a couple more thoughts on the suggestion of an 'in' operator
> (which others besides me have proposed).
> The current convention is that punctuation operators like == != < are
> numeric, while alphabetic ones like eq ne lt do string comparisons.
> An 'in' operator doing string comparison follows that convention.
> While you could also have an equivalent in== operator, in my
> experience that operation is much less common than the string version.
> As in Python, 'in' could work for both arrays and hashes:
>    $x in @array
>    $x in %hash    # same as exists $hash{$x}
> With the auto-dereferencing introduced in recent perls, the RHS could
> be an array or hash ref.
>    $x in $hash_ref    # same as exists $hash_ref->{$x}
> I do not envisage the 'in' operator being part of some grand scheme
> which will replace all functionality provided by smartmatch, but just
> propose it as a simple operator which is useful in its own right and,
> in my opinion, can make for clearer and more concise code.
> --
> Ed Avis <>

 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

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