I've been mulling how to make things like LET that are able to create new bindings outside of the USE-style nesting of blocks.
So instead of writing:
use [x] [ x: 10 ... use [y] [ y: 20 ] ... ]
You could write:
let x: 10 ... let y: 20 ...
The hope is that developments in virtual binding could make this feasible enough to become a replacement for "locals gathering" from doing a deep walk on function creation.
But the LETs Would Cease Visibility At The End Of The Block...
...that means it's kind of lame when you want to write:
while [let value: take block] [ print ["Took:" value] ]
If VALUE is only visible for the condition block, you can't use it in the body. So you have to write:
let value while [value: take block] [ print ["Took:" value] ]
So here we have a situation where a block has built up bindings, and you want to know those bindings so you can use them in another block.
This would suggest that DO would have an option to give you another result besides just the value...the context that was built up while the evaluation was taking place.
Also: BLOCK! From EVALUATE (DO/NEXT) Changes Binding
In a world with a LET that builds up state as it runs, there's a complicating effect in if you do single evaluation steps across blocks.
>> pos: evaluate [let x: 1, let y: 2, print [x + y]] == [, let y: 2, print [x + y]]
The block you get back there has to be somehow remembering its binding of x: 1 if it's not going to throw that information out. This means the block is now virtually bound into a frame that was built for the execution and then torn down. That throws a bit of a wrench into my suggestion that it could avoid creating new virtual bindings on each LET...because it's no longer going to be clear that it's the same frame. Nothing is stopping you from this:
pos2: copy pos do pos do pos2
It can't glue y into the same context for where x lived on both, or it would get two y's.
Another hiccup in this whole concept is that if you virtually bind things, they currently become CONST. If every EVALUATE virtually bound to the frame of the block you were running, that would rule out casual modification of partially evaluated blocks.
Wily stuff. It's hard to imagine ways of making this work at all, much less performantly, but more abilities are around now for experimenting with it.