New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
state(@a) = #12421
Comments
From @cpansproutThis hasn’t been implemented yet, and I do not see any existing ticket for it. (state @a) = ... is not supposed to have the assign-once behaviour. state(@a) = ... and state @a = ... are (if Ι understand correctly). Flags: Site configuration information for perl 5.17.4: Configured by sprout at Mon Aug 27 23:00:20 PDT 2012. Summary of my perl5 (revision 5 version 17 subversion 4) configuration: Locally applied patches: @INC for perl 5.17.4: Environment for perl 5.17.4: |
From @cpansproutOn Sun Sep 16 12:15:05 2012, sprout wrote:
I believe this reasoning makes sense in Perl 5 (even if it is not It is ‘state’ (with its arguments) that is treated specially on the LHS So that means state(our @foo) = ... should assign to the package Right? -- Father Chrysostomos |
From [Unknown Contact. See original ticket]On Sun Sep 16 12:15:05 2012, sprout wrote:
I believe this reasoning makes sense in Perl 5 (even if it is not It is ‘state’ (with its arguments) that is treated specially on the LHS So that means state(our @foo) = ... should assign to the package Right? -- Father Chrysostomos |
@cpansprout - Status changed from 'new' to 'open' |
From Eirik-Berg.Hanssen@allverden.noOn Tue, Oct 16, 2012 at 11:45 PM, Father Chrysostomos via RT <
... and evaluate the RHS only once (as in the scalar case). Oh, and as eirik@bluebird[00:31:09] I think "evaluate the RHS only once" means that the RHS is _also_ part of Eirik |
From @ap* Father Chrysostomos via RT <perlbug-comment@perl.org> [2012-10-16 23:50]:
$ perl -E'my (our To my mind that is a “no”. So far `state` is basically just another (Maybe it is a missed opportunity that isn’t spelled `state my`. I care For those times where you really need this functionality you might be { state $init = do { our $foo = 1 } } Not as obvious as I would like, but at least not ugly either. And with the aid of Devel::CallSite you can sugar it up to the point of stately { our $foo = 1 }; -- |
From @cpansproutOn Tue Oct 16 17:31:22 2012, aristotle wrote:
But then would return \state my $x give the same variable each time?
My question is more ‘Where do we draw the line?’ than ‘Isn’t this useful?’ Where do *you* think we should draw the line between state controlling What I like about my explanation above between the difference between -- Father Chrysostomos |
From [Unknown Contact. See original ticket]On Tue Oct 16 17:31:22 2012, aristotle wrote:
But then would return \state my $x give the same variable each time?
My question is more ‘Where do we draw the line?’ than ‘Isn’t this useful?’ Where do *you* think we should draw the line between state controlling What I like about my explanation above between the difference between -- Father Chrysostomos |
From @ap* Father Chrysostomos <perlbug-comment@perl.org> [2012-10-17 03:00]:
My impulse was to contradict this until I finally realised I’m wrong. I felt that `my` and `our` are about visibility, while `state` is the So I withdraw that argument, and thanks for helping me clear my thoughts Though on the converse, this only strengthens my argument that `state`
That *is* attractive, but I don’t know if it’s really a good idea. Consider the status quo here: $ perl -E 'sub x { state(my $x) = "a"; $x++ // "(undef)" }; say x; x; say x' How (else?) should that work? And why? If `state` is just another kind If I take your proposal at face value, it would become this: $ perl -E 'sub x { state(my $x) = "a"; $x++ // "(undef)" }; say x; x; say x' I.e. the upshot of your proposal would be that assignment to a `state` I don’t think I like having `state` be two different things. Also, currently this is an error: $ perl -E 'sub x { my(state $x) = "a"; $x++ // "(undef)" }; say x; x; say x' What would you want this to do? What would you want *this* to do if list assignment were no longer $ perl -E 'sub x { state($x, my $y) = ("a", "b"); $x++ // "(undef)" }; say x; x; say x' Does this assign "a" to $x only once but "b" to $y every time? If not, The way I understand it you’d give $y the state variable treatment here, Note that if we decide that you will never be able to mention more than That would then imply the following: $ perl -E 'sub x { my(state $x) = "a"; $x++ // "(undef)" }; say x; x; say x' This is not terrible. It would also imply that the state($x, my $y) I’m not happy. Any which way I turn it, this is messy, with no apparent way to handle Regards, |
From @rjbsA lot of the discussion on this ticket was about the behavior of state(our...) or state(my...) This problem has been designed away by v5.24, in which nested declarators are illegal. I'm writing a fair bit of code targeting v5.24 right now, and I've found that there are many cases where I would really like to use "state @arr = ...;" Since the concerns of this ticket *seem* to be gone, now, can we press forward? -- |
From zefram@fysh.orgAmusingly, the present prohibition on list initialisation of state $ perl -Mfeature=state -lwe 'my $i = 0; sub f { (state ($a, $b), undef) = ($i++, "z"); print $a, $b; } f(); f(); print $i' whereas either of those pairs of parens in the absence of the other is $ perl -Mfeature=state -lwe 'my $i = 0; sub f { state ($a, $b) = ($i++, "z"); print $a, $b; } f(); f(); print $i' Fortunately, the consensus semantics that we started out aiming for, Anyway, using the flags that are already available in ops is not quite As a first step, I think we should allow unparenthesised "state @a" Without going beyond the clues offered by the existing flags, we could -zefram |
From zefram@fysh.orgI wrote:
Over the last couple of days I've gone back and forth on whether it's Code to permit initialisation of unparenthesised variables is now in blead Rather than permit a handful more scenarios under the current op flag -zefram |
From @xsawyerxOn 11/04/2017 11:03 PM, Zefram wrote:
But do we need to? Considering nested declarations are not allowed, when is distinguishing
This is great. This basically now supports "state @x=" but not yet "state(@x)=" because |
From zefram@fysh.orgSawyer X wrote:
It's important because, under the principles we favour, they would have This whole fuss arises from the rather dubious design decisions that -zefram |
Migrated from rt.perl.org#114932 (status was 'open')
Searchable as RT114932$
The text was updated successfully, but these errors were encountered: