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

Re: given/when/~~ "final" thoughts (ha ha ha)

Thread Previous | Thread Next
From:
Ricardo Signes
Date:
September 20, 2012 21:16
Subject:
Re: given/when/~~ "final" thoughts (ha ha ha)
Message ID:
20120921041632.GB23226@cancer.codesimply.com
* Father Chrysostomos <sprout@cpan.org> [2012-09-16T16:01:31]
> Ricardo Signes wrote:
> >   when { ... } # block evaluates true
> 
> I discovered a gotcha with that:
> 
>     given(42) {
>       when {/4(.)/} {
>         print $1, "\n"; # prints nothing
>       }
>     }
> 
> This would need to be documented.

That's a bummer, but at least it's consistent with the rest of the language.

If I was a frothing lunatic, I might suggest that the two blocks should share
their lexical environment.  But I'm not.

> >   when breaks the enclosing topicalizer
> 
> Define topicalizer.  Does it include while(<>)?

Yes.  When I spoke with Damian at OSCON about given/when, he specifically
mentioned "closing the hole" on the fact that not all the topicalizers were
being hooked onto by when.

I'm not violently attached to `when` kicking back to its enclosing topicalizer,
rather than its innermost enclosing loop, but I do like it.  If it's a serious
point of contention, I'll poke at it a bit and see if Damian wants to offer any
particular defense, etc.,

> > I wanted to post that this is a design that would get accepted.  The
> > reservation of the final case, rather than eq/==, in smart match, lets us
> > figure out whether future work on improving num-v-str can be put to work here.
> 
> Have you noticed the sprout/smartpatch branch?

I did and have not yet built it. :-/

> I found Smylers’ argument (<20120905143040.GZ1742@stripey.com>) convincing so
> I implemented it like this:
> 
>  $x ~~ undef
>  $x ~~ $overloaded
>  $x ~~ sub{}
>  $x ~~ qr//
>  $x ~~ $anthing_else # fall back to eq

I like falling back to eq and had proposed it at one point, but there was so
much support of smartly picking == or eq based on improvements available with
the future flags improvements Chip was pitching that holding back on that
behavior for now seemed warranted.

Also, this stuff gets grosser:

             given ($z) { when (1)  { ... } } # when(1)  means ($z == 1)
  my $x = 1; given ($z) { when ($x) { ... } } # when($x) means ($z ~~ $x)

...so now we're back to the "literal value 'works' both ways" as opposed to
letting the literal value work and the variable say, "sorry, no smart matching
against simple scalars."

Frankly, I'm really feeling a lot of antipathy to the whole thing right now.
But it's late, I probably just need sleep.

> But that makes ~~[] do the wrong thing silently in existing code, so adding
> this before the last case would improve it:
> 
>  $x ~~ $other_ref # croak

In my proposal of Summer 2011, I suggested something like "[]~~qr/../ still
means =~, and of course it will be fatal because you'll be using strict
stringification."  I think that's a better general solution than another
special case in ~~.  Then again, if we don't fall back to eq, it's all
academic.

> And when() just does smartmatch.

So, in your branch, when(5) is stringy, and if you want numeric, you say
when { 5 == $_ } ?

> Two things I’m not volunteering to do are:
>   • Coordinate with autodie maintainers about getting it adjusted.
>   • Write the documentation (don’t forget to warn about $1 being
>     unavailable in when {/(1)/} { $1 })

That's fine, of course.  Also, I mailed Tom C. for some input on this whole
kerfuffle, since he shares my general loathing for the smartmatch situation,
but so far I've gotten no reply.  I hope it's just because he's enjoying a long
pleasant vacation somewhere nice.

> And what do you think of the new whirled order for given/when/last/next on
> that branch?  Also, should break and when produce exiting warnings (they do
> not currently)?

I think they should, dont't you?

> >   case (EXPR) BLOCK
> > 
> > equivalent to:
> > 
> >   if ($EXPR) { BLOCK <next unless continue> }
> > 
> > That would be a reasonable thing to keep around if we decide we can't get to an
> > acceptable smartmatching future.
> 
> This does not seem to fit with the subject, so now I really do not know what
> you are thinking.

That was me saying, "maybe the best thing about the whole given/when/~~ mess
was a quick way to say "if-with-a-next," which we could salvage even if we
poured everything else down the drain.

I feel like no matter what, given/when/~~ are really balancing on the very very
thin edge of "can be worth the complexity."  I really do not relish the idea of
all the required work being done only to realize that we've gone from
unbearable to just barely bearable.

-- 
rjbs

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