On 01 Oct 2014, at 07:48, Father Chrysostomos <spr...@cpan.org> wrote: > Does ‘state’ govern ‘:=’ the way it governs ‘=’? In other words, just as > this: > > state $x = 1; > > only assigns to $x once (per closure), does the same apply to this? > > state $x := $y; > > I can’t find anything in the specs that implies that it does. > > The reason I ask is that I am currently implementing binding for Perl 5, but > the syntax is different— > > \$x = \$y; > > (The reason for the different syntax is that, when we tried to use :=, we > could not find a coherent way to handle edge cases [e.g., flattening vs not > flattening]. Reusing existing Perl 5 syntax seemed the most straightforward > and intuitive approach.) > > —and I am debating whether \state $x = \$y should bind only once or every > time the surrounding code is executed. I could argue it either way (though I > am leaning toward the latter), so I thought to find out what Perl 6 does.
It would seem that binding state variables will be something that will be prohibited in Perl 6, until such time we find a good use case for it. [15:55:36] <lizmat> well, all of this was because of a question of Father Chrysostomos (a very productive p5p contributor) on p6l [15:57:01] <jnthn> OK. Well, I'll leave it at, I'm happy enough with the current semantics, so unless TimToady++ feels they have to chnage, then I'm not inclined to do much about the status quo. [15:57:44] <jnthn> (Where by "the current semantics" I mean, what Moar does, and I'm about certain what we do on JVM. I don't actually know how things are on Parrot.) [15:57:59] <lizmat> eh, but the current semantics silently do the wrong thing, no ? [15:59:11] <jnthn> lizmat: Depends how you define the semantics of state. [15:59:44] <jnthn> lizmat: Note that if you go binding a temp or let var you are in equal trouble. [16:00:03] moritz wouldn't mind compile-time disallowing rebinding temp/let/state vars [16:00:05] <jnthn> 'cus those are certainly about value, not container [16:00:14] <lizmat> moritz +1 [16:00:18] <jnthn> I took state to be wanting the same semantics [16:00:31] <jnthn> Yeah, I could go with a conservative approach of "just disallow it" [16:00:53] <lizmat> I'll answer FC Hope this answer your question, Liz
