List::Util::first() don't work into when() context #12219
Comments
From explorer@joaquinferrero.comThis is a bug report for perl from explorer@joaquinferrero.com, Example: say $List::Util::VERSION; my @probe = ( my @temp = @probe; my $item = 'temp1'; given ($item) { Flags: Site configuration information for perl 5.10.1: Configured by Debian Project at Thu Jun 30 22:25:10 UTC 2011. Summary of my perl5 (revision 5 version 10 subversion 1) configuration: Locally applied patches: @INC for perl 5.10.1: Environment for perl 5.10.1: |
From @b2gillsOn Sun, Jun 24, 2012 at 1:25 PM, Joaquin Ferrero
This is because 'given' uses a lexical '$_', and 'first' also uses '$_'; If you replace 'given' with 'for' it works as expected |
|
The RT System itself - Status changed from 'new' to 'open' |
From @rjbsAlternately, you can continue using given/when and refer to $::_ in your first block, rather than I suggest ditching given/when, though. |
From [Unknown Contact. See original ticket]Alternately, you can continue using given/when and refer to $::_ in your first block, rather than I suggest ditching given/when, though. |
|
@rjbs - Status changed from 'open' to 'resolved' |
From @rgarciaOn 27 June 2012 13:35, Ricardo SIGNES via RT <perlbug-comment@perl.org> wrote:
C<our $_> should work, too.
Or fix the internal macro that gives access to $_ from XS. |
From @LeontOn Wed, Jun 27, 2012 at 2:37 PM, Rafael Garcia-Suarez <rgs@consttype.org> wrote:
There is UNDERBAR, but it does make code more complicated because it Leon |
From @cpansproutOn Wed Jun 27 05:37:31 2012, rgs@consttype.org wrote:
Or just make given localise $'_, as everybody expects it to. Or just deprecate given/when outright. -- Father Chrysostomos |
From @rjbs* Father Chrysostomos via RT <perlbug-followup@perl.org> [2012-06-27T11:18:15]
You are on my shoulder, whispering, but are you an angel or a devil? -- |
From aaron@priven.comOn Wed, Jun 27, 2012 at 8:18 AM, Father Chrysostomos via RT <
given isn't, of course, the only way to make a lexical $_ -- a simple "my And lexical $_ has other problems -- for example I wrote here why the http://perlmonks.org/?node_id=958820 -- |
From @cpansproutOn Wed Jun 27 10:53:54 2012, perl.p5p@rjbs.manxome.org wrote:
:-) That was enough to make me laugh out loud. -- Father Chrysostomos |
From [Unknown Contact. See original ticket]On Wed Jun 27 10:53:54 2012, perl.p5p@rjbs.manxome.org wrote:
:-) That was enough to make me laugh out loud. -- Father Chrysostomos |
From @rgarciaOn 27 June 2012 21:07, Aaron Priven <aaron@priven.com> wrote:
To me that's more a prototype problem than an lexical $_ problem. The purpose of lexical $_ is to hide $_ from other scopes, in Now what we want is to mimic builtins that can access the current $_. My current opinion (since a couple of years actually) is that |
From @rjbs* Rafael Garcia-Suarez <rgs@consttype.org> [2012-06-27T18:03:16]
Mine also, for some time now. A lexical $_ is fine, but one should get it "Nobody" writes "my $_" without thinking about it, because it's a weird thing I wonder how much code would break were given to stop lexicalizing. Even -- |
From aaron@priven.comOn Wed, Jun 27, 2012 at 3:03 PM, Rafael Garcia-Suarez <rgs@consttype.org>
I'm not sure what difference it makes to call it a prototype problem. I my $_; works while my $_; does not (at least in pure perl). On Wed, Jun 27, 2012 at 5:12 PM, Ricardo Signes
I disagree. It is weird only because you are familiar with the usual "local -- |
From @cpansproutOn Wed Jun 27 17:13:21 2012, perl.p5p@rjbs.manxome.org wrote:
Steffen Müller, could you run a smoke against sprout/givendefsv? With that branch, I get this (compared with 5.16.0): $ perl5.16.0 -le 'use 5.01; given (23) { foo() } sub foo { when(23) { $ perl5.16.0 -le 'use 5.01; given ($x) { $_ = 3; foo() } sub foo { print $ ./perl -le 'use 5.01; given ($x) { $_ = 3; foo() } sub foo { print $x }' -- Father Chrysostomos |
From @cpansproutOn Wed Jun 27 18:19:21 2012, sprout wrote:
Oh dear. RT’s Unicode bug strikes again. If you have already started with 874b0bd15 (the original head), please Ten cubes! :-) -- Father Chrysostomos |
From @sciuriusRicardo Signes <perl.p5p@rjbs.manxome.org> writes:
I don't expect much code to break, given that I don't think given/when If we are going to deprecate given/when, we shouldn't wait much longer. -- Johan |
From @cpansproutOn Wed Jun 27 23:13:44 2012, jv wrote:
+27.93 -- Father Chrysostomos |
From @phaylonOn Thu, 2012-06-28 at 08:13 +0200, Johan Vromans wrote:
Might it not make more sense to change the $_ it populates to a regards, |
From @dmcbrideOn Thursday June 28 2012 3:21:32 PM Robert Sedlacek wrote:
This is what I would like to see as well. The whole given/when thing may not At $work, I already had to convince another team to drop their "use Switch" Anyone coming from a C or shell background is going to be used to this idea, Instead, if the real problems with given/when are a) lexical $_ and b) Going back to lexical $_ should only be done when we can find a way to get it tl;dr - I agree with Robert :-) Please don't remove given/when when the fix to |
From @cpansproutOn Thu Jun 28 06:53:40 2012, dmcbride@cpan.org wrote:
We have always had for/last.
We don’t have to get rid of it to deprecate it. Just stop ‘use 5.18’
But there is also the icky scoping of when and break, and how they Also, when’s algorithm for guessing when you want implicit smartmatch is Oh, and let’s deprecate smartmatch while we are at it. :-) Despite the -- Father Chrysostomos |
From @phaylonOn Thu, 2012-06-28 at 08:24 -0700, Father Chrysostomos via RT wrote:
Which can be quite confusing when it's used for non-looping.
Would the first part not be fixable by requiring 'when' to be inside I can't really comment on the smartmatch detection issues, since I'm not
How about instead of deprecating it, the undesirable features of it are regards, |
From @cpansproutOn Thu Jun 28 09:17:43 2012, rs@474.at wrote:
I’ve never had that problem. That use of for has been documented (in
when can break out of for. We also have to take given(1){foo()} sub
That’s why it’s needed. But it doesn’t work well at all. It goes
So it’s a generic ‘do something funny with this object’ operator? Do -- Father Chrysostomos |
From @doyOn Thu, Jun 28, 2012 at 09:38:45AM -0700, Father Chrysostomos via RT wrote:
That is pretty close to what rjbs proposed last year. -doy |
From @phaylonOn Thu, 2012-06-28 at 09:38 -0700, Father Chrysostomos via RT wrote:
True, and yet, when I see 'for' I think 'loop' :) The only exception is s{$}{.pm}, s{::}{/} for @packages;
I know that it does that now. I'm proposing that it doesn't. Since a
Maybe it shouldn't do *that* then? :) Forcing people to use 'if' and an when (nontopical { $x == $y && $z eq 23 }) { which simply ignores the passed topic and evaluates the expression by
Well, not a "do something funny" but "a complex match". But in general yeah, I'm just not sure about deprecating "everything". Anyway, these things might be more maintainable in the long run if they regards, |
From @doyOn Thu, Jun 28, 2012 at 07:08:50PM +0200, Robert Sedlacek wrote:
And those were the (only) other cases that rjbs proposed keeping(: -doy |
From @lizmatOn Jun 28, 2012, at 6:38 PM, Father Chrysostomos via RT wrote:
FWIW, I always use "foreach" for the looping case, and "for" for the non-looping case. It makes for some sort of sanity. Liz |
From @LeontOn Thu, Jun 28, 2012 at 6:17 PM, Robert Sedlacek <rs@474.at> wrote:
I agree, it's ugly.
That would completely break my uses of it. I'm not interested in a
It's awful. In Smart::Match, I actually had to overload not just
I agree. Leon |
From @tseeOn 06/28/2012 03:19 AM, Father Chrysostomos via RT wrote:
Running. Look for progress at http://users.perl5.git.perl.org/~tsee/progress.html and for output at http://users.perl5.git.perl.org/~tsee/givendefsv/ --Steffen |
From mail@steffen-mueller.netOn 06/28/2012 05:45 AM, Father Chrysostomos via RT wrote:
Currently running a smoke of Chip's chip/magicflags6 branch. Progress at: When that's done, I'd be glad to smoke this for you. Alternatively, Cheers, |
From @chipdudeOn 6/28/2012 9:49 AM, Jesse Luehrs wrote:
Once my magic flags patch is accepted, we can make string and number and |
From @cpansproutOn Thu Jun 28 23:03:02 2012, smueller@cpan.org wrote:
Thank you. The only new failures are due to timing or network issues. I think we can safely make given alias $_ the way for does. -- Father Chrysostomos |
From @ap* Reverend Chip <rev.chip@gmail.com> [2012-06-30 01:50]:
No, not in fact. It makes it almost certain to work for values that came It will work much better, but it cannot work right. (It may not need to work right if it is close enough. I am sceptical and Regards, |
From @chipdudeOn Wed, Jul 11, 2012 at 07:27:35AM +0200, Aristotle Pagaltzis wrote:
Well, that's a fair cop. I wonder, though... WARNING - WILD ASS GUESSING AHEAD ... if my patch's ability to correctly discern the RIGHT operand type might $a ~~ 42 would be true if $a="42", while being false and not warning if $a="foo"? |
From @ap* Rev. Chip <rev.chip@gmail.com> [2012-07-11 09:35]:
Part of me is feeling queasy; part of me is thinking this might just Regards, |
From @b2gillsOn Wed, Jul 11, 2012 at 2:29 AM, Rev. Chip <rev.chip@gmail.com> wrote:
Am I right to assume that perl -E'$a = 42; $b = "$a text"; say $b ~~ $a ? 1 : 0' will print out: 1 instead of: 1 as it does now |
From @chipdudeOn 7/11/2012 8:33 AM, Brad Gilbert wrote:
In short, yes. |
From @cpansproutOn Fri Jun 29 16:46:56 2012, rev.chip@gmail.com wrote:
Which part of the baby? Your patch, if I remember, exposed the Traditionally Perl has had typed operators and (mostly) typeless values, -- Father Chrysostomos |
From @chipdudeOn Wed, Jul 11, 2012 at 12:38:41PM -0700, Father Chrysostomos via RT wrote:
Yes, insofar as conversions no longer lose track of the original type.
Can't agree. Culture is subjective and interactive; we both form it and are
I can't undererstand this argument. It's not that I disagree with it, I
Now I know you're missing the point. Dumping modules already distinguish |
From @ap* Rev. Chip <rev.chip@gmail.com> [2012-07-12 00:35]:
This is a nonsensical statement. If it were true on the face of it then
Two responses, FC: 1. In most cases such code will be as buggy as code that tries to look 2. It does not make a good argument against the patch because people Ultimately I believe Chip’s patch really makes no serious difference to
I think the issue with his argument is that you overestimate the impact
And the reason it isn’t causing problems is that no one is relying on Essentially your patch, to me, boils down to more reliable serialisation Therefore I like it. Regards, |
From @chipdudeOn Thu, Jul 12, 2012 at 11:35:42AM +0200, Aristotle Pagaltzis wrote:
That's fair. I like Perl's pre-smartmatch operators fine. I only intend to Smart match is a separate issue. If people want smart match they'll have
You're making more sense than I was. So: OK. Father C: ^^ |
From @cpansproutOn Thu Jul 12 02:36:51 2012, aristotle wrote:
That’s exactly what I’m afraid of.
But that will be hard to back in the face of this ‘new feature’.
Actually, there is nothing wrong with looks_like_number, as code using
I still think looks_like_number is a better approach in most cases.
If that is the reason for it, then I am not opposed, as long as the Let’s not have a repeat of the Unicode bug.
Not at all. Perl 6 has +| and +&, so why can’t Perl 5? Probably
-- Father Chrysostomos |
From @chipdudeOn Fri, Jul 13, 2012 at 12:15:17AM -0700, Father Chrysostomos via RT wrote:
Sadly, yes, some errors^Wodd design decisions are beyond fixing. Say, the |
From @ap* Father Chrysostomos via RT <perlbug-followup@perl.org> [2012-07-13 09:20]:
I don’t really think so. A big part of the problem with the UTF-8 flag That people would do the wrong thing in the face of such overwhelming There is no need for the magicflags patch to repeat these mistakes. It Some people will do the wrong thing regardless. You cannot help that.
Well… it depends, on what it’s trying to do. If you’re trying to write There are other cases… I know I had code that I couldn’t make work well With Chip’s patch this problem would go away.
Yes well, as I said, depending on what you are doing.
Absolutely. See above.
Hmm. Hmm. The idea that this could be fixable is more than a little tempting… Do you think we could also eventually untangle C<x> from C<x()> the way Regards, |
From @chipdudeOn Fri, Jul 13, 2012 at 11:27:32AM +0200, Aristotle Pagaltzis wrote:
I was *just* thinking the same thing this morning. It all depends on what My current best choice is "created_as_string", "created_as_integer", We can bikeshed the name, but the principle seems right to me. (I expect these would go in Scalar::Util.)
Exactly so. |
Migrated from rt.perl.org#113818 (status was 'resolved')
Searchable as RT113818$
The text was updated successfully, but these errors were encountered: