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

Reply via email to