On Fri, Feb 03, 2006 at 06:45:23AM +0000, Luke Palmer wrote:
: On 2/3/06, Dave Whipp <[EMAIL PROTECTED]> wrote:
: > sub factorial(Int $x) {
: > temp state Int $result = 1;
: > $result *= $x;
: > factorial $x-1 if $x > 2;
: > return $result if want;
: > }
: > say factorial 6;
:
: That's precisely what "env" variables are for. The right way:
:
: sub factorial(Int $x) {
: env $result = 1;
: my sub fact(Int $x) {
: $+result *= $x;
: fact($x - 1) if $x > 2;
: return $result;
: }
: fact($x);
: }
:
: Of course, you can view env variables as implicit parameters. Given
: that, this function might be able to reduce to:
:
: sub factorial(Int $x) {
: env $+result = 1; # expecting $+result
: # param, default to 1
: $+result *= $x;
: fact($x - 1) if $x > 2;
: return $result;
: }
Hmm, that won't work in my current mental model, where an "env" is
used only in the outermost dynamic scope to declare the existence of
that outermost scope, and within that scope it behaves exactly like a
"my" variable. But that means that the assignment happens every time,
not as some kind of default.
If you don't have an outermost scope declarator, you've just basically
reinvented a less efficient version of globals and "temp", since "env
$+result" would always have to assume there was an outer dynamic scope
and scan outward to the root dynamic scope.
But that's just my current mental model, which history has shown
is subject to random tweakage. And maybe "env $+result" could be a
special squinting construct that does create-unless-already-created.
Doesn't feel terribly clean to me though. If we stick with the +
twigil always meaning at least one CALLER::, then clarity might be
better served by
env $result := $+result // 1;
assuming that $+result merely returns undef in the outermost env context.
Larry
