Closures are much safer.

Perhaps I'm misunderstanding, but I was under the impression that the Perl6 code:

sub foo {
  state $bar;
  $bar++;
}
[download]

Was equivalent to the Perl5 code:

{
my $bar;
sub foo {
  $bar++;
}
}
[download]

Which is a closure if I ever saw one. How is this safer? I'm not trying to blindly disagree with you, I'm honestly curious why the closure is safer.

I believe BrowserUK's point is that if foo is just a global subroutine, there is no difference. On the other hand, suppose you had

package Bar;

sub new { ... }

sub foo {
  state $bar;
  $bar++;
  return $bar;
}
[download]

Then later...

$bar1 = Bar->new();
$bar2 = Bar->new();

$bar1->foo(); # returns 1, as you would expect
$bar1->foo(); # returns 2, as you would expect
$bar2->foo(); # returns 3, possibly unexpected
[download]

At least this is my understanding. Is this what you meant, BrowserUK?

jgallagher,
BrowserUk's response boils down to "don't use state variables as a replacement for class variables when doing OO". I agree with that. The argument that it will be easy to make this mistake is false though as p6 OO looks visually a lot different from p5 (method foo() vs sub foo() for instance). I am not saying caution isn't warranted, but this is just once case that doesn't negate the usefulness elsewhere.

Cheers - L~R

Update: I reworded my response to be clearer but I believe the spirit of the message was left in tact.

Yes. That is a good example of the possible surprise factor.

Now inherit Class Qux from Class Bar, and every time you call ->foo() from any instance of either class, state $bar will be incremented. This has the potential for an even bigger surprise factor I think.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

I don't think that's the type of closure BrowserUk is referring to. Think more of this perl 5 code:

sub genclosure {
  my $bar;
  return sub { $bar++; }
}
[download]

Each time you call genclosure, you get a new closure, a new state variable. You don't reuse the previously existing state variable.

So I would have to agree with BrowserUk's "very carefully" statement. The same as I would use your perl5 (global) closure code - very carefully. That said, I have probably about a half-dozen or so places where I need or want to cache data globally in my projects at work, so this would be very nice syntactical sugar for that. However, I also generate a few closures where this new idea could easily bite a junior programmer in the arse when they wonder why their data isn't returning properly. ("How did that counter get so high already?")

That said, I also generally avoided static in C as well, so that's not really surprising for me. After all, one generally looks at programming tasks from the basis of their experience - if it looks like a nail, that may be because all you have is a hammer.

Update: TimToady's response has cleared things up a bit, thankfully. It was looking a bit grim for state - although there is still some care to be taken. I'll have to think if I can figure out where I'd use this feature, if anywhere.

If that's what he meant, this would be the equivalent Perl6 code, using state:

sub genclosure {
  return sub { state $bar; $bar++; }
}
[download]

I'm still not seeing a difference in safety.

I am sure that neither you nor I have any confusion as to how state variables in Perl6 will work, but I want to respond to this as I think it may lead others astray. A variable's visibility declared with state is still restricted to the scope it was declared in. The difference from a regular lexicals is that if program execution comes back to that scope the variable is not re-initizalized and its previous value is restored. Update: TimToady has explained it much better.

In your example, foo() is a global sub, so there can never be two instances of it, but if foo() was a method, multiple instances of whatever class foo() was a method of, would all share the same %seen. Effectively, %seen becomes a Class variable. These can be useful--eg. counting the number of instances created or in existiance--but why not use a Class variable instead?

You are correct - variables declared with state can be used to simulate class variables just as the example I provided shows. In that case, OO didn't exist yet. Unlike p5, methods and subs will be very distinguishable in Perl6. That should make it easier to distinguish when it is more appropriate to use a class variable - but caution is warranted.

However, not having a similar possibility to control which handle, setting applied to $/ and $\ will affect, is worse. The separation and encapsulation of state is what makes OO so useful.

This is fixed in Perl6.

If P6 objects are going to be usable across threads, then using state varibles for singletons is going to produce potential problems where, for example, DB handles can only be used from one thread.

The bulk of your reply seems to be focused on how state declared variables may cause problems with OO. Nothing in my post indicated that's how I thought they should be used other than to say if you don't have OO yet - they make simulating it easier. The example I gave was that of a regular sub - not a method. I asked for examples of how others might use it. From your reply, I can assume you won't be using it for OO. Can you think of any other places you might use it for?

Hmm. I would need to understand the difference between state and local, and the scope on the namespace in which state variables live.

Ie. Does state $foo; refer to the same thing across packages, files, modules, threads?

In single threaded apps, a truely global (process wide) variable type has uses for things like DB handles, file handles, sockets, ports, etc. anything that is a truely process global entity.

Once you introduce threads into the equations, things get sticky. It very much depends upon the threading models supported by the OS and which of those models is used by libraries supplying services to your process as to whether things like DB handles can be safely used across threads or not.

One assumes that the state keyword came into being in order to support a particular scenario. A good description of that scenario, and the implications of would be nice to see.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

Not so! A class variable is accessible to all instances of a class. A state variable (assuming it behaves more or less exactly like a static variable in C/C++) is visible only within the declaring function, and if that function is a method, then it is restricted to the instance as well. It's actually a tighter scope than member variables with the same persistence.

The scope is constrainted to the method, but the potential to affect change to it is not!

Any instance that can call the method can change it's value. Any method in the same class can call the method, therefore any instance of the class can call the method, and unless it is somehow constrained, any instance of any subclass can call a method that will call a that method and so change it's state.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.