Front page | perl.perl5.porters |
Postings from September 2012
* Father Chrysostomos <sprout@cpan.org> [2012-09-02T19:06:43]
> > 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.
A reading from perlsyn:
> Furthermore, Perl inspects the operands of logical operators to decide
> whether to use smartmatching for each one by applying the above test to
> the operands:
>
> 9. If EXPR is "EXPR1 && EXPR2" or "EXPR1 and EXPR2", the test is
> applied recursively to both EXPR1 and EXPR2. Only if both operands
> also pass the test, recursively, will the expression be treated as
> boolean. Otherwise, smartmatching is used.
And a program to demonstrate it:
use 5.16.1;
package SM {
use overload 'bool' => sub { return },
'~~' => sub { 1 };
}
my $sm = bless {}, 'SM';
say($sm ? 'sm is true' : 'sm is false');
given ($sm) {
when ($sm && $sm) { say 'when was entered' }
}
Am I missing something, or are you?
Back to Sprout:
> [ ... ]
> What about objects that are not overloaded? What about qr//, which returns
> an object?
qr// objects are made ot behave like =~ qr//.
Objects that are not overloaded remain fatal.
> 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.
Way back when, around 5.10.x, I argued that we should require ~~ overloading
for ~~, not fall back to anything else. I think I was right then and merely
forgot about it until recently.
> 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. ?
Right. It avoids (a) ambiguity (b) breaking code when you /had/ &{} but /add/
qr and /not/ ~~. This was the concern then, too, but with regard to %{} and
@{} and object guts.
> Should 5 be a deprecation warning? Or just a croak?
I'd just make it fail. It's like saying "push $hashref" ;)
> 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.
I do: they're both like method calls on boxed values. You're saying
$arrayref->as_hash and it finds out, at runtime, that it can't.
> Also, would ~~ /.../ still be special-cased into ~~ qr/.../? If so, would
> when(/foo/) continue to work?
That's a very good question, and I'm not sure. It's tempting, isn't it? My
initial reaction, though, is no. It's just a little too special for just a
little too little gain.
> And would it continue to break m?...? like this?
Presumably not.
> > 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).
Of course! Think-o. :)
> > 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.
Any suggestions?
> And, since you have not answered it yet, should given respond to next?
Almost certainly. Was there ever any given (ha ha) reason not to? Is it fear
of changing the behavior of existing givens inside loops?
> 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.
Well, the issue is that when interacts with a topicalizer. It is going to do
its work based on the topicalization that has occurred, and so having its
implicit break behave like a 'next' on the relevant topicalizer is not
obviously nuts.
> 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}
If there is a "when BLOCK BLOCK" form then, yes, the first block has its own
lexical scope distinct from that of the second.
--
rjbs
Thread Previous
|
Thread Next