One problem, SET-BLOCK!s have not traditionally been considered in top level gathers. (Not because they were never intended to be, but because they are "new" and have had their semantics sort of hammering out over time.)
But if you can write:
wrap [
x: ...
]
It seems that you should be able to say:
wrap [
[x y]: ...
]
But SET-BLOCK! is dialected, so it gets a little complex. You don't want to make a variable for Z when you see [x (z)]:
, and you do want to make a variable for N when you see [^n (z)]:
Which reminds me, with CHAIN we're about to get META-CHAIN-WORDs, like ^foo:
... so you won't have to make a block to get a meta assignment. And we'd expect that to wrap too.
wrap [
^foo: ...
]
Brave new world. But @foo:
(evals to @foo:
, bound) shouldn't be collected, nor should $foo:
(evals to foo:
bound), and obviously not 'foo:
(evals to foo:
, unbound)
I'm also reminded that SET-BLOCK! needs to recurse for unpacking.
wrap [
[[a b] [c d]]: pack [pack [1 2] pack [3 4]]
]
I would expect a, b, c, and d to be collected by that wrap.
Well, there we see it's a blessing as well as a curse... if you didn't want the wrap semantics, you can escape them.
Given that I seem to be meandering about here, it may not be obvious...but things are really starting to tighten up. Things are coming into alignment, and the code is written in such a way that I can morph it around pretty comfortably despite the drastic upheavals. I will reiterate that without being able to build as C++, a lot of the reorganizations I do would be nigh impossible... so frontloading the R3-Alpha redesign effort with bringing C++ into it was not just worthwhile... it's the only reason the project can exist.