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

Re: fixing smartmatch just hard enough (and when, too)

Thread Previous | Thread Next
Jesse Luehrs
August 23, 2012 14:43
Re: fixing smartmatch just hard enough (and when, too)
Message ID:
On Thu, Aug 23, 2012 at 09:50:07PM +0200, Leon Timmermans wrote:
> > You're proposing that:
> >
> >     any(9,10,11) ~~ \&is_prime
> >
> > be equivalent to:
> >
> >    is_prime(any(9,10,11))
> >
> > but what if I want it to mean what it's supposed to mean:
> >
> >    any(is_prime(9), is_prime(10), is_prime(11))
> If «is_prime(any(9,10,11))» is not equivalent to «any(is_prime(9),
> is_prime(10), is_prime(11))», it's not a junction in the first place.
> It's just an abstraction that fakes it half of the time and leaks like
> a sieve the other half. Supporting them in a few circumstances and not
> in others seems silly and wrong to me. IMO doing them half-arsed is
> worse than not doing them at all.

This is kind of my main concern. It requires all implementations of
overloaded ~~ to be sure to handle a lot of different cases, which can
easily be forgotten (since testing on the lhs of ~~ is fairly uncommon).
This feels similar to the concerns that were raised about the pluggable
smartmatch - things would seem to work in the common case, but would
fail in the uncommon case if every smartmatch overload didn't explicitly
make sure to handle the pluggable form.

It's certainly possible to make things that work given this
implementation, but it pushes a lot of work back on the user, which
seems vaguely suboptimal to me (especially when is_prime(any(9, 10, 11))
should still work fine for any sane or reasonable implementation of


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