$n=1; #we have no idea which variables should be cascaded.
$subref=sub { return $n *3 };

print &$subref, "\n";
$n=2;
print &$subref, "\n";
[download]

use Cascade;

cascade $n;
cascade $m;
$n=1;

$m=$n;
$n=$m+1;
[download]

But I guess this isn't much different from screwing your reference count by doing a $a=\$a (except of course that that doesn't hang).

All speculation anyway, since I don't believe that there is any way to find what lvalue is affected by a variable reference.

For $foo = $bar + 1, the rhs is evaluated first and the result is stored in $foo. What you want is to store the rhs expression in $foo (ie, more or less a sub ref).

And, as swiftone says, every variable that has a cascaded variable on the rhs of its assignment is forced to become a cascade variable itself, with potentially dire results. Perhaps meltdown would be a better name :)

Define potentially dire results. :)

I only see this becoming a problem if you didn't think out your code before hand and just slopped everything in (which I do quite frequently btw). Having this new feature in the language wouldn't necessarily mean that everyone would use it, but it would guarantee yet another jump in the flexibility that perl is known for!

I see your point on assignment of the lhs vs. rhs, but I would assume that if a new datatype were created for this purpose, error handling would be done in quite a different manner. Maybe even set a new readonly variable! (has $^Y been reserved yet?)

I keep referencing back to spreadsheets (especially Excel) every time I look at the examples and alternatives everyone posted. It seems alot of monks were quite antipathetic about this idea, but then again I don't know anyone that uses all of the funtions in perl.

#!/home/bbq/bin/perl
# Trust no1!

Spreadsheets like MS Excel use rather complicated calculation engines to determine which cells are affected (effected?) by a change to a given cell. These engines are optimized for speed. I don't think they work in the manner you are suggesting (actually I wish I knew how the worked, there is some cool logic behind all that) but their debug engine (the recalc engine they use while debugging Excel) recalcs every cell on every delta, which is painfully slow.

I think there is a data type that allows you to alter the values later... Its called a subroutine. =)

Seriously. The way to do it is to define a subroutine with a void prototype and define it in terms variables. I think I saw a few posts earlier on that subject, but I'll reiterate:

sub x() { $y + $z }
local $y = 10;
local $z = 12;
print x;
[download]