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

[perl #120047] perl should enable "$_" for use before calling subs

Thread Previous | Thread Next
From:
Linda Walsh via RT
Date:
September 30, 2013 00:59
Subject:
[perl #120047] perl should enable "$_" for use before calling subs
Message ID:
rt-3.6.HEAD-31239-1380502735-1517.120047-15-0@perl.org
On Sun Sep 29 16:20:55 2013, perl.p5p@rjbs.manxome.org wrote:
> I *think* you are saying that $_ should be mutable in all cases, so
> that code
> expecting to assign to $_ will not die based in its input.
> 
> If this is a correct reading, it does not seem like a change for the
> better.
----
You have the basics, but with a few details missing.

I assume you've heard of the computer algorithmic paradigm, 
"copy on write" (abbrev. COW)

I'm saying that a sub that is NOT in the lexical scope of the
for loop (that aliased $_ to a constant), would be able to 
write to that variable which would become a localized copy that
would exist until the next "return from sub" is executed.

That way, no routines above the using routine would have any 
values modified.  Routines called by the modifying routine would
get the new $_ just as happens now in for/map/given if subroutine
calls are made from their interior.

It wouldn't change any code that relies on the value NOT changing.  Any
pre-existing code that relies on it not changing would not be in the
call-sequence of any routine that relies the original values maintained,
as any working code, now, cannot rely on "$_" working without taking
some extra measures.  None of those would be affected.

The only affect is to be able to make "$_" usable in called routines
that want to save and restore it.  In fact, if "$_" is not aliased
to a constant, nothing would change, as no COW would be needed ($_ is
not read-only).  Only in the case of a sub trying to use $_ would it
need a "virtualized" $_ that it can write to normally.

 


> When $_ is an alias to an existing variable that cannot be changed
> (because,
> for example, it is a constant) then trying to change it should be
> fatal.  The
> alternative is either to allow constants to be mutable or to make
> mutation
> sometimes have no effect on the intended variable.
----
I think my solution above answers your points.


> 
> Finally, you are still using "P.pm" in code that could be made easy to
> run with
> a stock installation, which makes it less trivial to run your example
> program.
----
I have enough problems with RSI in creating the simple test cases that I do.

But you make a point.  If you want to include P in CORE, I won't object.
If you don't want P to be in a stock installation, please don't blame
me, as I'm open to it.



> Please don't do that.  It's easier if you use Data::Dumper.
--
But those wouldn't have worked as well in the example program. and I
don't see "dumpvars.pl" as being part of the standard distribution
(ie:> dumpvars.pl
bash: dumpvars.pl: command not found).

==========
I Hereby grant you my P->DATA::Dumper shim:

use Data::Dumper;
sub P(;*@) { print Dumper(@_) }

.... added to the top of the program, the new output:
$VAR1 = 'case1';
$VAR1 = '%s';
$VAR2 = [
          3,
          undef,
          undef
        ];
$VAR1 = '%s';
$VAR2 = [
          3,
          1,
          undef
        ];
$VAR1 = '%s';
$VAR2 = [
          3,
          1,
          1
        ];
$VAR1 = 'case2';
Modification of a read-only value attempted at -e line 9.
---  (vs.)
case1
[1, ∄, ∄]
[1, 3, ∄]
[1, 3, 1]
case2
Modification of a read-only value attempted at -e line 7.
====
Either way, it still gives same error...

But if you want to make P part of core, I have some changes I'd need to
push and would really appreciate a code review (or skim-through) as a
check on my sanity -- but if not, as part of my code-push I'll just have
to make sure to beef up the tests... ;-)

Anyway discussing P is a red herring.  It's trivial to get around by
adding 2 lines (or convert it to print/printf or say or whatever floats
your boat, since it sorta replaces print/printf & say for most usages
and gives more compact output than DataDumper (though not as well
formatted; was designed for conciseness and minimizing typing).


I'm more interested in if you think my fix is still that problematic.
I would ask for *any* example (should be simple to disprove a positive
assertion, right -- hard thing is attempting to prove the absence of all
negatives for any value of 'X') which, in the general case, 
is NP-hard.









---
via perlbug:  queue: perl5 status: rejected
https://rt.perl.org:443/rt3/Ticket/Display.html?id=120047

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