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

Front page | perl.perl5.porters | Postings from September 2012

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

Thread Previous | Thread Next

From:

Father Chrysostomos

Date:

September 2, 2012 16:06

Subject:

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

Message ID:

69A8F1CA-BB37-4980-B665-76CEF4FF661C@cpan.org

Ricardo Signes wrote:
> * Peter Scott <Peter@PSDT.com> [2012-08-31T18:52:23]
> > On 8/31/2012 2:56 PM, Ricardo Signes wrote:
> > >* Peter Scott <Peter@PSDT.com> [2012-08-31T16:04:53]
> > >
> > >FC's suggestion was that when have three meanigns:
> > >
> > >   when (NUM)  { ... } # numeric literal, means $_ == NUM
> > >   when (STR)  { ... } # string literal,  means $_ eq STR
> > >   when (EXPR) { ... } # other expression, evaluates normally as in "if"
> > >
> > >Smartmatch (~~) was to be abolished.
> > Thank you for the painstakingly patient and polite education.  Now
> > light dawns.  Decoupling when and smartmatch.  Is that generally
> > agreed now no matter what?
> 
> It seems likely.  After all, when already only *usually* means smartmatch.
> For example, when($x ~~ $y) is boolean, not "$_ ~~ ($x ~~ y)".  when($x && $y)
> means "$_~~$x && $_~~$y"

No, actually it means $_ ~~ ($x && $y), making it more useless than ever.

It means, Match against $x if it is true; match against $y otherwise.

> but when(2 && 3) doesn't; it's constant folded.

Any time constant folding makes a difference like that, it’s a bug.  I added the OPpCONST_FOLDED flag recently to make things like that detectable.  But I have only used it to fix a few operators so far.

> So,
> since when is already "mostly smartmatch," making it "much more often
> smartmatch" is, I think, a big improvement.  The special cases we end up with
> under this proposal are very few (two, exactly) and not prone to the same sort
> of pain.
> 
> (For the current exceptions, consult perlsyn and search for "10 exceptional
> cases")
> 
> > >On the other hand, eliminating the first two tokens in "$_ eq
> > >'foo'" or "$_ == 4" in each when statement like that is a win.
> > 
> > I wonder if restoring just the operator part of that comparison
> > would be a suitable compromise?  Because then - if if it can be
> > parsed, and maybe it cannot, I have the bliss of ignorance there - I
> > would like to write things like:
> > 
> > when ( < 65    ) { say "Cold"       }
> > when { == 98.4 } { say "Tasty"      }
> > when { >= 75   ) { say "Hot"        }
> > default          { say "Just right" }
> > 
> > and then the presence of == vs eq would disambiguate the type and I
> > could use $BLOOD_TEMPERATURE etc.  [I also thought about 'when ( >=
> > 65 && < 75)' but my ignorance isn't *that* blissful.]
> 
> I see the temptation.  Binary comparisons are, in fact, one of the existing "10
> exceptions."  I think that the complexity isn't worth the win over this
> spelling, though:
> 
>   when { $_ < 65    } { say "Cold"       }
>   when { $_ == 98.4 } { say "Tasty"      }
>   when { $_ >= 75   } { say "Hot"        }
>   default             { say "Just right" }
> 
> Too many questions spring up when I think about operators with no lhs — and
> this is something that came up on IRC (with phaylon) and in person (with
> Damian).  I get nervous — and I'm not even the guy who'd have to implement the
> parsing changes! :-)

And what would this mean?

when ( < 75 ) { # > ) {
   ...
}

This?

when ( $_ < 75 ) {
   ...
}

Or this?

when ( readline " 75 ) { # " ) {
   ...
}

:-)

> 
> > >This means that ~~ has exactly four valid types of rhs, which you
> > >agreed were simple and probably memorable.
> > 
> > Yes, they are brief enough to be memorized.  I just wonder whether
> > they are coherent enough to make sense or cause a reaction of "Huh?
> > Why not also...?"  Because the place that reaction would be most
> > likely to cause damage is here, in three years, when this discussion
> > has been forgotten enough for someone to start a "Adding
> > functionality to ~~" thread.
> 
> I feel pretty confident that they make sense and that anybody could "just know"
> how a subroutine, regex, or undef would match something.  Overloaded objects
> are "obvious or not" on a case by case basis.

What about objects that are not overloaded?  What about qr//, which returns an object?

If we respect qr and &{} overloading, or if non-overloaded objects just croak, I still maintain that this is going to cause problems for module authors that want to add extra functionality to existing objects without breaking code that uses the modules.

Maybe the only reasonable chart would be this:

1. !defined($rhs)
2. overload::Method($rhs, "~~");
3. reftype($rhs) eq 'CODE'
4. reftype($rhs) eq 'REGEXP'
5. ?

Should 5 be a deprecation warning?  Or just a croak?

I still get the feeling that qr//-or-sub{} is too unlike anything else in Perl.  The only other place where perl croaks based on the argument type is in dereferencing.  And my brain doesn’t want to draw the parallel between smartmatch and dereferencing.

Also, would ~~ /.../ still be special-cased into ~~ qr/.../?  If so, would when(/foo/) continue to work?

And would it continue to break m?...? like this?

$ ./perl -Ilib -le 'sub match { print "foo" =~ m?foo? } match; match; reset; match'
1

1
$ ./perl -Ilib -le 'sub match { print "foo" ~~ m?foo? } match; match; reset; match'
1
1
1

> 
> As for the "why not also," having gone through so many posts about it, I would
> be sure to write a comprehensive bit of Pod on the matter. :-)
> 
> > >When has three behaviors: numeric literal, string literal, and
> > >"anything else," where the final case is taken as the rhs to a
> > >smartmatch, with the topic as the lhs.
> > 
> > That last case is mooted for abolition though, right?
> 
> No.  The exhaustive set of "when" behaviors would be:
> 
>   given ($input) {
>     when (1)   { ... } # if $input == 1
>     when ('x') { ... } # if $input eq 'x'
>     when ($x)  { ... } # if $input ~~ $x
>   }
> 
> And further demonstrated:
> 
>   given ($input) {
>     when (undef)  { ... } # if $input ~~ undef
>     when ($x + 2) { ... } # if $input ~~ ($x + 2)
>     when ($_ > 1) { ... } # if $input ~~ ($_ > 1)
>   }
> 
> Under FC's proposal, which would eliminate ~~ entirely:
> 
>   given ($input) {
>     when (1)   { ... } # if $input == 1
>     when ('x') { ... } # if $input eq 'x'
>     when ($x)  { ... } # if $x
>     when (undef)  { ... } # if undef

Of course, one would write when (!defined).

>     when ($x + 2) { ... } # if ($x+2)
>     when ($_ > 1) { ... } # if ($_ > 1)
>   }

We already have many operators that imply $_.  Maybe what we really ought to be doing is extending that.  If we can come up with new ways to imply $_ in arbitrary expressions, then if() would benefit, too.

And, since you have not answered it yet, should given respond to next?

And here is another aspect of when/default that makes the way it breaks special:

for (3) {
  for my $x (4) {
    when (3) {}
  }
  warn "exited inner";
}
warn "exited outer";

That prints "exited outer at - line 7".  So when doesn’t just do ‘next’ inside for.

I think that should change.

Here is another question about your when proposal:  What are the scoping rules for when{}{}?  If the lhs is a block, then these will not be the same:

    when(my $x=qr//){warn $x}
    when{$_ =~ (my $x =qr//)}{warn $x}

Thread Previous | Thread Next