--- Uri Guttman <[EMAIL PROTECTED]> wrote:
>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> Larry wrote:
>> : sub foo() {
>> : has $s //= 0; : $s ++ ;
>> : }
>> : : print foo, foo, foo;
DC> Futhermore, this approach opens another vermiferous can. I
DC> would argue that C<//=> is the wrong way to initialize it,
DC> since that effectively prevents C<undef> values from being
DC> used with such variables.
> so don't put the //= 0 there and it will be undef. in fact why would
> the // be needed if you can just do:
> has $s = 0 ;
> also i think has implies a class level attribute here which is not
the
> same in my mind as
> my $s is static = 0 ;
> which is private to the sub (and any nested subs).
DC> Hence, I would argue, one ought to simply mark it with a trait:
> my use of is static was a trait. i chose 'is' for that reason. it was
> a compile time trait that the var was to be allocated (and optionally
> initialized) only once and it would be not on the stack and would
keep
> its value between calls to foo().
DC> sub foo() {
DC> my $s is retained = 0;
DC> $s++;
DC> }
DC> Other possible trait names:
DC> is kept
DC> is preserved
DC> is permanent
DC> is reused
DC> is saved
DC> is stored
DC> is restored
DC> is irrepressible
DC> Yes, the names are all considerably longer than a C<has>
DC> declarator, but I see that as a bonus. Persistent behaviour by
DC> a lexical is unusually enough that it ought to be loudly and
DC> clearly marked.
DC> Oh, and note that I very deliberately did not suggest
DC> C<is static>!
> but that is a good name IMO. $s is static vs dynamic (on the
> stack). the other overloaded meanings of static from c/c++ are
> baggage we can drop.
What other meanings?
static int foo = 0; /* File scope private symbol. */
static int func() /* File scope private symbol. */
{
static char buf[100]; /* Function scope permanent lexical symbol. */
/* ... */
}
>From where I sit, the static-inside-a-function meaning is the only
"overloaded" one, in that it suggests that the lexical symbol with
function scope also has file-level allocation (which in fact it does in
most implementations).
I see two uses for "static" being discussed:
1: static as a synonym for "is private":
our $shared is private = 0;
sub x() { ... $shared ... }
sub y() { ... $shared ... }
And let's face it -- C<our> means "common", which is just exactly what
C<static> means. Maybe we should bring back "common" as a keyword
-since formats are out of core, FORTRAN is underrepresented in P6.
2: static as a synonym for "call-spanning private symbol":
sub x()
{
static $x = 0;
print $x++;
}
x; # prints 0
x; # prints 1
There are some interesting questions that haven't been asked about
scope yet.
For instance: Is there an incompatibility between package scope and
program scope?
If I say
macro static($name, $traits) is parsed(/however/)
{
$OUTER_SCOPE::declare($name, $traits);
}
Then there's the suggestion that unloading a package would, for static
declarations with package scope, destroy the variable.
Whereas if static points to "program scope" (e.g., by inserting a
globally scoped symbol with a mangled name) then it won't be destroyed
when the package is unloaded. Viz:
macro static($name, $traits) is parsed(/however/)
{
::declare("__" ~ Package() ~ "__" ~ Function() ~ "__" ~ $name,
$traits);
}
So, what should "static" (function scope, call-spanning) variables
actually do?
=Austin
