So here we are three years later, and, well...
We can make PARSE complicit with virtual binding, adding a context to lookup even after fetching a rule out of a variable:
>> rule: [copy data [some integer!]]
>> obj: make object! [data: _]
>> parse/inside [1 2 3] [some rule] obj
== [1 2 3]
>> obj/data
== [1 2 3]
I'm having a hard time thinking of what sort of coherent way you could do this kind of thing if PARSE was not going to be complicit. How can you set an absolute rule about when binding should follow through a fetched-variable link or not?
For instance, if you write:
use [name] [
name: "Bob"
do code
print ["Hello there," name]
]
The general assumption we have is that name: "Bob" would not transmit through the DO.
So that's the kind of limit you'd expect with:
parse [1 2 3] inside obj [some rule]
That form would only apply to the block, and not jump through to RULE.
In any case, I have a very inefficient version of PARSE/INSIDE working. Currently it applies to blocks and groups:
>> rule: [(foo "hi")]
== [(foo "hi")]
>> obj: make object! [foo: func [x] [print ["Foo" x]]]
>> parse "ab" ["a" rule "b"] ; without /INSIDE
** Script Error: foo is ~unset~ (use GET/ANY to GET voids)
>> parse/inside "ab" ["a" rule "b"] obj
Foo hi
== "ab"
But I can imagine wanting different contexts for block vs group. It also seems like you could want it to be more granular... pushing the /inside specifications into the rules. But I'm not sure how you'd do that.