Marcus, you are incorrect when you summarize the documentation as noting that modifying a reference taken to a substring is forbidden. That's wrong.

You're right. I expressed myself so badly that what I wrote was factually wrong. I'll update my original response. Thanks for pointing out my mistake.

Incidentally, though, as long as no substr is involved, you can run as many substitutions as you wish on an indirected reference. Hence:

[~/perl/monks]$ ./test
abc
[~/perl/monks]$ cat test
#!/usr/bin/perl -l
use warnings;
use strict;

my $a = 'aaa';
$_ = \$a;
$$_ =~ s/aa/ab/;
$$_ =~ s/ba/bc/;
print $$_;

[~/perl/monks]$
[download]

That $_ = \$_ construction is interesting. It yields a variable for which $_ == $$_ == $$$_, etc. No matter how many times you indirect it, the type and value of $_ don't change. There must be some code that breaks when you do that!

Markus

This proved to be the final piece in my puzzle. Instead of passing an lvalue ref to a selected substring into deeper levels of recursion, I have to pass the (aliased) target string, and the start/end pair of teh selectd substring. The deeper level can then use substr to modify the appropriate bit of the target without falling into the trap of re-using a modified lvalue ref.

Passing the three salient pieces of information around separately is less convenient that doing so nicely encapsulated in the lvalue ref, and it forces me to do the math of combining the start-end pair passed at a given level with the start-end pair selected from within it, before passing them in deeper.

It also forces me to manipulate the start/end pair I receive to account for any shrinkage or growth of the selection made at this level or any deeper levels called from this level--within my caller.

Perfectly doable at this level, but it would also be perfectly doable--and more efficient and convenient--if Perl did that for me. I've no doubt that it could be done by Perl given the interest of someone with sufficient tuits at that level.

Perhaps the most diconserting thing about this whole thread is that Perl is silently converting an lvalue ref to a normal scalar when a second modification through it is attempted, and thus discarding the changes made by that second change!

That ought to be a red-flag. Maybe it should be the subject of a perlbug?

It seems that someone already did offer a patch that would perpetuate the lvalueness of an LVALUE ref when it is modifed. Indeed, it was done in response to a perlbug diotalevi raised following an earlier exposition of mine on the subject here.

However, it would appear that patch was rejected in favour of the quick fix of (silently) converting a modified LVALUE to a mortal SV if a further attempt to modify it was encountered.