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

Re: fixing smartmatch (again (still))

Thread Previous | Thread Next
From:
Jesse Luehrs
Date:
August 28, 2012 12:42
Subject:
Re: fixing smartmatch (again (still))
Message ID:
20120828194205.GX11137@tozt.net
On Tue, Aug 28, 2012 at 02:43:48PM -0400, Ricardo Signes wrote:
> 
> Let's try again.
> 
> First, though, I want to say that I was really happy with the discussion about
> this.  It was on topic, interesting, and helpful.  Even if there *was* a holy
> ton of it!
> 
> ## The New ~~ Operator
> 
>     $a      $b                  Meaning
>     ======= =======             ======================
>     Any     undef               ! defined $a
>     Any     ~~-overloaded       ~~ overloading is used
>     Any     Regexp, qr-ol       $a =~ $b
>     Any     CodeRef, &{}-ol     $b->($a)
>     Any     Any                 fatal
> 
> So, this is the table I proposed in July 2011, and it's what I think we're back
> to.  No special cases.
> 
> There is no question of how ($x=5) somehow became ambiguous, because if $x
> contains 5 or "5" is is not allowed as the smartmatcher operator, period.  Use
> Smart::Match and say stringwise(5) or numwise(5), or pass sub{$_==5}
> 
> If both 'qr' and '&{}' are overloaded, '~~' must be overloaded to disambiguate.
> 
> Switches are still okay.
> 
> ## The new behavior of given/when
> 
>   given ($x) {
>     when ($y)  { ... } # $x ~~ $y
>     when (4)   { ... } # $x == 4
>     when ('4') { ... } # $x eq 4
>   }
> 
> Deferred/computed values of any sort mean smart match.
> 
> Two dead-simple special cases: Numeric literals mean ==.  String literals mean
> eq.
> 
> If you want one case for $x eq a or b or c, then:
> 
>   given ($x) {
>     when (stringwise any qw(a b c)) { ... }
>   }
> 
> ## What about what Father C. said?
> 
> Sprout proposed that smartmarch be jettisoned and that `when` always evaluate
> its parameter as a boolean expression, save for the same simple cases above.
> 
> For the "$x eq a or b or c" example, that gives us at least two simple choices:
> 
>   given ($x) {
>     # Here, "any" returns a "junction" that distributes the eq
>     when ($_ eq any qw(a b c)) { ... }
>   }
> 
> Or:
> 
>   given ($x) {
>     # Here, stringwise implies the "$_ eq"
>     when (stringwise any qw(a b c)) { ... }
>   }
> 
> My thoughts on this are:
> 
> • I like the idea that we can have matcher objects that can be passed in
>   more succinctly than a sub.  ->set_matcher(qr/../) or ->set_matcher($obj)
>   both seems simpler to me than ->set_matcher(sub { /.../ }) or
>   ->set_matcher(sub { $obj->match($_) })
> 
> • If we do, then Smart::Match and many other things keep working as they have
>   without needing to be rewritten.  This is nice.
> 
> As Father Chrysostomos suggests, perl does not *need* smartmatch.  Really, it
> doesn't need need features.  My question is, does perl benefit more from this
> fix to smartmatching than it does from simply removing it?  I believe it does.

As far as I can tell, this resolves all of the (few) misgivings I had
about the previous version of the proposal. I would be very happy to see
this happen.

-doy

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