--- 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