Front page | perl.perl5.porters |
Postings from August 2012
On Fri, Aug 17, 2012 at 12:58 AM, Ricardo Signes
<perl.p5p@rjbs.manxome.org> wrote:
> ## The New ~~ Operator
>
> $a $b Meaning
> ======= ======= ======================
> Any undef ! defined $a
> Any ~~-overloaded ~~ overloading is used
> ~~-ol Any ~~ overloading is used (reversed)
> Any CodeRef, &{}-ol $b->($a)
> Any Regexp, qr-ol $a =~ $b
> Any Simple $a eq $b
> Any Any fatal
>
> This is a nearly a subset of the current behavior. Here are some major points:
I'm not quite sure about the reversed overloading, but otherwise
that'd be my list too.
> ## Core Junctions
>
> Well, that's why we have junctions. Remember those? Of course you do, they're
> fantastic.
>
> if ($x ~~ any( qw( John Paul Ringo ) )) {
> tune_strings;
> } else {
> tap_drumps;
> }
>
> We already have very nice junctions in Perl6::Junction. We bring that into the
> core (with a new name) and we get nice useful ways to put tests together. We
> also get them anywhere else we want them. For me, that's "all over the place."
> I bet it will be for lots of other people, too.
Yeah, we should totally have that in core.
> ## Backcompat and ~~
>
> My anxiety over backward compatibility for ~~ is not gut-wrenching. Still, it
> would be nice to do what we can.
>
> After a lot of talk about making ~~ pluggable across different scopes, I think
> it's a non-starter. It's just not the kind of thing we can plug this way,
> because of the way in which we expect it to be used. If we expect users to
> pass a test from their code to some other code, they need to know how that code
> will use it. It needs to be the same everywhere.
>
> It would be nice to provide a best-effort backcompat with a deprecation warning
> when possible. I'd like to know how good that effort can be. Since the new
> table is in many ways a subset of the old one, I think it can be pretty good.
I think a CPAN-smoke for this could be most helpful. We don't really
know how much code would break, even if it probably isn't all that
much.
> ## Fixing given and when
>
> I think we already fixed given pretty hard. I need to look at bit more at it,
> but let's take it as "fixed enough" for now.
>
> when!
>
> Oh, when, how you trouble me.
>
> I propose that `when(X)` *always* means `$_ ~~ X`. All of the special cases
> for parsing and interpreting the inside of when can go. They can all be
> reduced to `when(sub{...})`. I would also smile upon `when({...})` acting as a
> test block. (Since you can't put a hashref on the rhs of ~~ anymore, there is
> no ambiguity.)
>
> The exceptions (from perlsyn's "Experimental Details on given and when") are:
>
> EXCEPTION WAS IS NOW
> 1. subroutine call -- when (foo())) -- when ({ foo() })
> 2. regex match -- when ( /foo/ ) -- when (qr/foo/)
> -- when ( $_ !~ /foo/) -- when ( none( qr/foo/ ) )
> 3. smart match -- when ($a ~~ $b) -- when ({ $a ~~ $b })
> 4. comparison -- when ($a lt $b) -- when ({ $a lt $b })
> 5. some builtins -- when (eof) -- when ({ eof })
> 6. negation -- when (! $x) -- when ({ ! $x })
> 7. bool filetest -- when (-r) -- when ({ -r })
> 8. flip flops -- when ($a .. $b) -- when ({ $a .. $b })
> 9. conjunction -- when ($a && $b) -- when ( all( $a, $b ) )
> or when ({ $a && $b })
> 0. disjunction -- when ($a || $b) -- when ( any( $a, $b ) )
> or when ({ $a || $b })
I agree this is an issue, but I'm really not sure I like this
solution, not that I have a better idea.
> Also, `when` should be valid inside an auto-topicalizing `while`, providing an
> implicit next, making its behavior more generic so that `when` can be used
> safely everywhere that it makes sense.
Yes please.
Leon
Thread Previous
|
Thread Next