referenced constant loses readonlyness #11929
Comments
From zefram@fysh.orgCreated by zefram@fysh.orgOn a threading Perl, a list-mode refgen applied to a constant will $ perl-single -MDevel::Peek -lwe '$sref = \123; Dump $sref; ($lref,undef) = \(123,2); Dump $lref;' I presume that this copy is being performed by S_refto() in pp.c, in $ perl-single -MDevel::Peek -lwe 'Dump 123' The srefgen case behaves itself because it's constant-folded before the $ perl-single -MDevel::Peek -lwe 'sub dumpref($) { Dump \$_[0]; } dumpref 123' It seems awfully wrong for S_refto() to ever copy the referent. I don't Perl Info |
From @cpansproutOn Fri Feb 03 08:03:52 2012, zefram@fysh.org wrote:
It’s necessary so that ops with TARG appear to return a different value -- Father Chrysostomos |
|
The RT System itself - Status changed from 'new' to 'open' |
From zefram@fysh.orgFather Chrysostomos via RT wrote:
It's tempting to write a module that replaces *every* const op with I think the workaround that I need at this point is a function that -zefram |
From zefram@fysh.orgI wrote:
Now on CPAN as Scalar::Construct::constant(). -zefram |
From @cpansproutOn Tue Jul 03 11:19:55 2012, doy wrote:
Pretty much. But fixing it is not as simple as ‘fixing’ it. "$a$b" returns a new value each time, so there is no reason for it to be In the case of built-in operators (even const ops), I lean toward the It’s hard to solve, really. How should constants behave? If a constant -- Father Chrysostomos |
From [Unknown Contact. See original ticket]On Tue Jul 03 11:19:55 2012, doy wrote:
Pretty much. But fixing it is not as simple as ‘fixing’ it. "$a$b" returns a new value each time, so there is no reason for it to be In the case of built-in operators (even const ops), I lean toward the It’s hard to solve, really. How should constants behave? If a constant -- Father Chrysostomos |
From @rurbanOn Tue, Jul 3, 2012 at 3:18 PM, Father Chrysostomos via RT
FYI: My branch typed/ro branch adds support for const pads which is missing F<https://github.com/rurban/perl/commits/typed/ro> |
From @cpansproutOn Tue Jul 03 13:18:19 2012, sprout wrote:
Interestingly, copy-on-write can affect whether a ‘constant’ is constant: use overload; Ouput: no error And with ‘use constant’: no warnings 'redefine'; Simply turning on the read-only flag has no effect on copy-on-write -- Father Chrysostomos |
From @cpansproutOn Tue Jul 03 13:18:19 2012, sprout wrote:
OK, so there are three arguments regarding whether values return by 1) It doesn’t cause any harm to make it modifiable, so why not? It’s I’m afraid the second one sounds stupid because I am biased against it That leaves us with 1 and 3. I propose that we make threaded and • Operators that return different values depending on parameters ($a+$b, for ( sub(){ 42}->() ) { $_++ } Furthermore, ‘use constant’ usually copies the values anyway. I’m going to go head and work on this. You’d better yell loudly if you -- Father Chrysostomos |
From @ikegamiOn Mon, Jun 10, 2013 at 9:14 PM, Father Chrysostomos via RT <
Not they're not. The list is flattened into an array of modifiable scalars >perl -e"for (1..2) { for ((), 1..3) { print $_++; } print qq{\n}; }" (The parens ensure that the ".." is a range operator rather than the part I tried to fix it, but there was no consensus as to how to fix it. IIRC, Modifiable was better for backwards compatibility if nothing else. |
From @cpansproutOn Mon Jun 10 19:15:59 2013, ikegami@adaelis.com wrote:
I had forgotten the exact implementation. At least *conceptually* they
I was trying to come up with a self-consistent overarching plan that Keeping it modifiable while fixing the bug is simple: Set the PADTMP -- Father Chrysostomos |
From @chipdudeOn 6/10/2013 6:14 PM, Father Chrysostomos via RT wrote:
It's an argument from parsimony: Perl should not do unnecessary work. |
From @ikegamiOn Mon, Jun 10, 2013 at 11:38 PM, Father Chrysostomos via RT <
Correct. I don't care much either way. My analysis: Allowing "writable constants" allows more code like the following: my @a = map { s/^\s+//; s/\s+\z//; } <$fh>; I'm not sure if that's a good thing or not. On the plus side, it saves you my @a = map { my $s = $_; $s =~ s/^\s+//; $s =~ s/\s+\z//; $s } <$fh>; On the con side, things get interesting if you change the input from a my @a = map { s/^\s+//; s/\s+\z//; } @b; # @b gets changed too. Another possible downsides of having "writable constants" is that it might Does any of this matter to me? I doubt it will ever come up. |
From @cpansproutOn Mon Jun 10 20:38:52 2013, rev.chip@gmail.com wrote:
No, but it’s wrong. :-) A single read-only SV can suddenly turn into -- Father Chrysostomos |
From @nwc10On Mon, Jun 10, 2013 at 11:28:09PM -0700, Father Chrysostomos via RT wrote:
I realise. But it's bugging me a lot that if the name is "constant" it should It's not "I was expecting it not to be modifiable" but more "the names used to
I'm still not comfortable that this is "fix", at a language design level. I think that "we can do this" is coming at it from the wrong end. Start with "what should the semantics be?" and then make the implementation Nicholas Clark |
From @cpansproutOn Tue Jun 11 01:20:55 2013, nicholas wrote:
That’s precisely what
I’m trying to get to that, but we seem to have a disagreement above. For me, the term ‘constant’ doesn’t necessarily have to be ‘read-only I feel strongly that sub(){42} and sub(){return 42} should behave the If you feel equally strongly that ‘use constant foo=>42; ${\foo}++’ I could implement it *that* way (inlinable subs are not necessarily (BTW, the way that PADMY and PADTMP currently interact is completely -- Father Chrysostomos |
From @nwc10On Tue Jun 11 14:53:37 2013, sprout wrote:
Sorry. I'd missed this.
No. To my mind, strongly, constant means "constant" in the sense of (Although in that example, $x won't be immutable, as it's a copy of
This is a good point, I don't have a strong view on that, but I can
Yes, I think that decoupling the behaviour of sub foo(){42} from sub foo() { $a; } isn't to be treated as a closure is an utter hack. Changing the implementation of constant.pm to always avoid subroutines, } elsif (@_) {
I'm not familiar enough with it to be able to cite why without My head seems to be overfull, not everything fits, and stuff that Nicholas Clark |
From @cpansproutOn Fri Jun 14 06:09:56 2013, nicholas wrote:
We might not agree on the reasons, but at least here we agree on what
I want to kill that code. $a could change after \&foo has been referenced.
Yes, that could work perfectly well.
For a long time now, it has bothered me that list constants are not The way it is currently implemented, there is nothing constant about
Because whether a pad slot is in use is stored in the value, no two pad I’m still discovering things, and each new discovery makes me want to
I hope this bit hasn’t leaked out: commit 05d04d9 Don't clone the contents of lexicals in pads. ... Notice you check the refcount here: + if(SvREFCNT(oldpad[ix]) > 1) { Further down: + /* SvREFCNT(oldpad[ix]) != 1 for some code in threads.xs It seems to me you simply forgot to delete the comment. -- Father Chrysostomos |
From @chipdudeOn 6/11/2013 2:53 PM, Father Chrysostomos via RT wrote:
This is impossible unless what you mean is to make the second parse as |
From @chipdudeOn Mon, Jun 10, 2013 at 11:28:09PM -0700, Father Chrysostomos via RT wrote:
You've missed the point, I think. For Perl to make a read-only SV is good If that SV is the same as some other SV, then fine, no harm per se; and when Meanwhile, if copies of that SV are made due to some other necessity, fine; I don't care deeply about this, but I want the argument to be understood. |
From @demerphqOn 11 June 2013 23:53, Father Chrysostomos via RT
*ahem* You also felt like that about split and IMO chose the worst way
Given above I think you will have to forgive me for questioning The opposite interpretation is just as and perhaps more reasonable Yves perl -Mre=debug -e "/just|another|perl|hacker/" |
From @cpansproutOn Sat Jun 15 00:31:49 2013, demerphq wrote:
Well, it’s good that we are diligently keeping watch over each other. :-)
Yep, and that also broke a CPAN module by changing split "$space". When
That is why I am writing to the list. :-) I have already tweaked my plans twice based on input from others. I honestly don’t think I can fix everything without breaking some CPAN -- Father Chrysostomos |
From @cpansproutOn Sat Jun 15 00:31:49 2013, demerphq wrote:
Are you saying that you disagree with my general approach (and that what -- Father Chrysostomos |
From @HugmeirOn Tue, Jun 11, 2013 at 6:53 PM, Father Chrysostomos via RT <
Could someone explain/link to what the argument against this is? Having |
From @cpansproutOn Sat Jun 15 08:55:02 2013, Hugmeir wrote:
I don’t think it’s so much an argument against it, as it is simply that What Chip was referring to is the fact that sub(){42} is documented to I don’t have a problem with continued disparity in the case of sub The other thing is that ‘use constant’ uses sub(){}, and Nicholas Clark So, again, there are not really arguments against having them behave the -- Father Chrysostomos |
From @demerphqOn 15 June 2013 15:49, Father Chrysostomos via RT
Arguably in that case the problem was that I /wasn't/ watching over I was a bit grumpy when I made that comment, and I apologize for being catty. What I should have done is caution you against a rush to judgement and Or something like that.
Indeed. I think however this was definitely in the end a change for the better.
Just to be clear, I am firm believer that the old expression "you need A bit of CPAN fallout for a good change to perl is acceptable damage in my book. Yves -- |
From @demerphqOn 15 June 2013 15:50, Father Chrysostomos via RT
Maybe both. Not sure. :-) My understanding is that the issue at hand is that these two subs: sub foo(){ 42 } behave differently in the face of the code like: ${\foo}++ $ perl -le'sub foo(){return 42} ${\foo}++; print "ok";' And the question is should do something about it and if so what. Which You seem to be taking the position that a) is off the table, and that You also have suggested that we should separate subs from constants. I cheers |
From @cpansproutOn Sun Jun 16 02:44:14 2013, demerphq wrote:
I am not suggesting that sub(){42} stop being inlinable. The cases in $ ./perl -Ilib -le 'sub foo(){42} for(foo) { print \$_; print \$_; }' This is under ithreads. Why am I getting two different memory addresses? And ${\$_} is currently *modifiable* under those circumstances, too. So Also, I have found the difference between ‘42’ and ‘return 42’ to cause -- Father Chrysostomos |
From @chipdudeOn Tue, Jun 18, 2013 at 04:24:23PM -0400, Eric Brine wrote:
Because they're different languages. Perl passes by reference; C does not.
That statement is pretty much the opposite of right. |
From @ikegamiOn Wed, Jun 19, 2013 at 2:40 PM, Rev. Chip <rev.chip@gmail.com> wrote:
huh? code first design later??? |
From @ikegamiOn Wed, Jun 19, 2013 at 2:40 PM, Rev. Chip <rev.chip@gmail.com> wrote:
(Please forget my earlier knee-jerk post.) The issue I was addressing is whether constant literals generate mutable |
From @chipdudeOn 6/19/2013 2:26 PM, Eric Brine wrote:
Ah, I understand now. It's just that you're wrong. The above is *not* Hashes can be locked (as I always do with objects), Moose attributes can Literals in Perl are readonly, and that's good; a "use constant" |
From @ap* Reverend Chip <rev.chip@gmail.com> [2013-06-19 23:55]:
No one did want otherwise.
Repeating a nonsequitur won’t turn it into an applicable argument, |
From @cpansproutOn Tue Jun 18 11:16:21 2013, rev.chip@gmail.com wrote:
The reason I am conflating these, er, eight or so issues is that fixing Fixing the copying under ithreads (BTW, it is also a bug under Since it has the potential to break code, we need to consider the larger
Already fixed in the sprout/padconst branch, but doubtless you will
I consider the seniority argument to be false (respecting of course, I (and others, too) think it was a bad design decision to conflate the Now, witness how inconsistent it really is: <perlsub.pod> How is one to know when constant folding is going to occur? It varies sub rule () { '-' x 70 . "\n" } That code worked fine in perl 5.16. In perl 5.18 it croaks, because x Also: sub fooo() { sprintf "%s", "hello" } But: use locale; So efficiency tweaks in the compiler can change the way these things are Also, we have another anomaly: $ ./perl -Ilib -e 'sub p() { __PACKAGE__ } for (p) { $_++ }' Another point: Here is a quote from perlop.pod: <perlop.pod> Like C, Perl does a certain amount of expression evaluation at Note the last three words. If we combine what perlsub says with what I suggest we apply this patch: Inline Patchdiff --git a/pod/perlsub.pod b/pod/perlsub.pod
index 027d7be..7fff252 100644
--- a/pod/perlsub.pod
+++ b/pod/perlsub.pod
@@ -1365,7 +1365,7 @@ starts scribbling on your C<@_> parameter list. Ouch!
This is all very powerful, of course, and should be used only in moderation
to make the world a better place.
-=head2 Constant Functions
+=head2 Inlinable Functions
X<constant>
Functions with a prototype of C<()> are potential candidates for
@@ -1409,7 +1409,7 @@ the constant folding doesn't reduce them to a
If you redefine a subroutine that was eligible for inlining, you'll get
While I don’t necessarily agree, I am willing to compromise. So let’s
Then let’s stop using that word for nullary subs whose bodies consist -- Father Chrysostomos |
From @cpansproutOn Wed Jun 19 14:50:33 2013, rev.chip@gmail.com wrote:
If I’m using perl, I shouldn’t have to worry about that, since perl will -- Father Chrysostomos |
From @rjbsOn Tue Jun 18 11:16:21 2013, rev.chip@gmail.com wrote:
Chip, I appreciated your several "wait, let's clarify stuff" posts in this * Father Chrysostomos via RT <perlbug-followup@perl.org> [2013-06-20T20:57:33]
Sprout has summed up my longstanding feelings about "constant" subs. I think Explicit constification, with 'use constant', is, well, explicit. Hooray! (By the way, I was amused by this bit of verbal dodge in constant.pm: "It is I am of course open to being convinced that I am totally wrong, but I feel My hunch is "not much," considering the way that constant subs have been able -- |
From @cpansproutOn Fri Jun 14 08:39:07 2013, sprout wrote:
If we allow list constants to be attached to CVs (as AVs) and inlined, -- Father Chrysostomos |
From @cpansproutOn Wed Jun 26 17:25:09 2013, perl.p5p@rjbs.manxome.org wrote:
I have a branch ready, called sprout/padconst. It hasn’t broken Last I heard, smueller was not able to do full CPAN smokes. I suspect I expect the breakage to be small enough that we could merge this to May I merge it? It will allow about 10 tickets to be closed. -- Father Chrysostomos |
From @rjbsI was hoping for some more commentary on this, but seeing as none is forthcoming, I think you |
From @cpansproutOn Fri Feb 03 08:03:52 2012, zefram@fysh.org wrote:
That has been fixed in commit 82b84d0. On Sat Oct 06 22:10:52 2012, sprout wrote:
This was fixed in 1913067. On Tue Jun 11 14:53:37 2013, sprout wrote:
They do, as of d244020. On Fri Jun 14 06:09:56 2013, nicholas wrote:
137da2b removed that hack. On Fri Jun 14 08:39:07 2013, sprout wrote:
We don’t need a constlist op. I implemented this in commits 6f1b3ab,
15635cb fixed that, too. On Sun Jun 16 06:48:26 2013, sprout wrote:
This particular cased is fixed by 8e079c2. The surrounding commits
This is the one unresolved issue left in this ticket. If I apply the POD is too limiting. Can we revive #95784 perhaps? -- Father Chrysostomos |
From @cpansproutOn Mon Jun 10 18:14:00 2013, sprout wrote:
This part was done in commit 2484f8d. -- Father Chrysostomos |
From zefram@fysh.orgFather Chrysostomos via RT wrote:
The position to which you refer comes from a conceptual distinction The position, then, is an instance of Occam's razor: one should not There is a certain amount of difficulty in applying this idea to I think this state, of almost everything being mutable by default, is a I recommend Henry Baker's paper "Equal Rights for Functional Objects" The end result of applying Occam's razor to the existence of variables -zefram |
From @cpansproutOn Fri Jul 26 09:17:22 2013, zefram@fysh.org wrote:
Considering that \ and foreach can autovivify, I do not find that If $a+$b returns a value, not a variable, then we could say that \ and This makes it similar to the way @a and %h work on the lhs of Likewise, \ imposes a context that requires that a scalar variable be (Note that the term ‘variable’ does not necessarily exclude read-only Under that model, there is no reason why something called a constant Whether we should follow that model is hard to say. The other model, -- Father Chrysostomos |
From @cpansproutOn Fri Jul 26 00:28:04 2013, sprout wrote:
I just applied the change to the paragraph, without the header change, -- Father Chrysostomos |
From zefram@fysh.orgFather Chrysostomos via RT wrote:
The usual term for this is "lvalue context". A variable (that can vary) It is instructive to compare against C. The C equivalent of Perl's \ Are you going to document \'s variable-generating semantics? -zefram |
From @cpansproutOn Wed Jul 31 02:42:52 2013, zefram@fysh.org wrote:
I’m not sure how to go about that, nor do I think it is necessary. I This bare value vs variable distinction is not something that is In we want to put it anywhere, it should go under the documentation for One thing that makes this difficult is that constants are currently At this stage, I am willing to leave things inconsistent, as the changes -- Father Chrysostomos |
From zefram@fysh.orgFather Chrysostomos via RT wrote:
If the behaviour is consistently thus, then we could document a general I think it is vitally important that we document which situations create
It's not necessary to cast the documentation in those terms. It's a
OK, but we do need to document the behaviour. Especially so if it's a -zefram |
From @demerphqOn 26 July 2013 18:16, Zefram <zefram@fysh.org> wrote:
I just wanted to thank you for this post. IMO it could be the start of cheers, -- |
From @cpansproutOn Wed Jul 31 09:17:27 2013, zefram@fysh.org wrote:
Actually, I fixed that in commit 2484f8d.
The only inconsistency left here is in constant.pm, and I documented it
How does the attached patch look to you? -- Father Chrysostomos |
From @cpansproutInline Patchdiff --git a/pod/perlfunc.pod b/pod/perlfunc.pod
index 4de31ac..390c2df 100644
--- a/pod/perlfunc.pod
+++ b/pod/perlfunc.pod
@@ -94,6 +94,13 @@ L<perlapi/PL_keyword_plugin> for the mechanism. If you are using such
a module, see the module's documentation for details of the syntax that
it defines.
+The return values of functions are generally new variables, meaning that
+you can take references to them and modify them through those references.
+Evaluating the same function call twice (in a loop or subroutine) produces
+two different variables. Functions returning true or false generally
+return the same two read-only scalars each time, though this is not always
+consistent and may change in the future.
+
=head2 Perl Functions by Category
X<function>
diff --git a/pod/perlop.pod b/pod/perlop.pod
index 4c26fe7..0792710 100644
--- a/pod/perlop.pod
+++ b/pod/perlop.pod
@@ -21,6 +21,13 @@ repetition or list repetition, depending on the type of the left
operand, and C<&>, C<|> and C<^> can be either string or numeric bit
operations.
+The return values of operators are generally new variables, meaning that
+you can take references to them and modify them through those references.
+Evaluating the same operator twice (in a loop or subroutine) produces two
+different variables. Operators returning true or false generally return
+the same two read-only scalars each time, though this is not always
+consistent and may change in the future.
+
=head2 Operator Precedence and Associativity
X<operator, precedence> X<precedence> X<associativity>
|
From zefram@fysh.orgFather Chrysostomos via RT wrote:
Seems woolly. As there's a localised disclaimer of future changeability, If the intention is to guarantee some behaviour, state precisely Also, I'd be wary of widely guaranteeing creation of new variables at -zefram |
Migrated from rt.perl.org#109744 (status was 'open')
Searchable as RT109744$
The text was updated successfully, but these errors were encountered: