Implement state declarator

[masak]

I see no need for an our declarator in 007 — we went a different path with modules and exports — but state would be quite useful, to indicate that a variable is declared as belonging to "all the entries of a block".

func foo(n) {
    my s = 0;
    s += n;
    say(s);
}

foo(1);    # 1
foo(2);    # 2
foo(3);    # 3

func bar(n) {
    state s = 0;
    s += n;
    say(s);
}

bar(1);    # 1
bar(2);    # 3
bar(3);    # 6

I imagine the state macro could use COMPILING:: and symbols, just like the final implementations of ff and once would. (And, perhaps more interestingly, ff and once could use state, thereby encapsulating all the craziness in one place. In other words, state might end up a useful building block for macros, but still non-primitive and implementable in pure 007.)

Speaking of encapsulation, note that state with an assignment has once semantics. (Think of how often the assignment to 0 in state s = 0; above ought to run.) It's as if it leaks a little bit. I see that that's the case... and yet that doesn't much sway me that we made the right call in #279/#369. It was a tradeoff; making it the other way would have created other pain points.

Hm. I guess we could make state a statement... but that feels inconsistent when my is a term, doesn't it? So I guess we're left with doing something contextual to make the state leaf node communicate its once semantics up to a (possible) neighboring = node.

This issue could use some implementation, both of state itself, of ff and once using state, and of the contextual bit just mentioned. So I'm slapping "currently-needs-more-design" on it until we have that.

[masak]

Oh! Remember the "clones get different states" semantics from #207. It applies here also. (Edit: Re-reading this in 2021, it seems that OP fully realized this. G'ah, I feel like I'm a time traveler from the future moderating a discussion between versions of myself spread out over time.)

[masak]

The once type from the package sync is an interesting take on this, essentially reducing the challenge to an object that does its own synchronization. As long as it has a gensym'd name, it works splendidly, and is even thread-safe.

[masak]

Speaking of encapsulation, note that state with an assignment has once semantics. (Think of how often the assignment to 0 in state s = 0; above ought to run.) It's as if it leaks a little bit. I see that that's the case... and yet that doesn't much sway me that we made the right call in #279/#369. It was a tradeoff; making it the other way would have created other pain points.

For what it's worth, STD.pm6 agrees. state (like my) is a "scope declarator", which is a term. So at least grammatically, we're good.

The issue/worry comes from turning state from a "built-in declarator" (where the interpreter/compiler controls the semantics, and easily can give the RHS once semantics) into a user-definable macro (where that semantics now ends up "outside" the term itself, and so needs special treatment, which in itself feels non-compositional).