Apropos was about exploring late rebinding of blocks into different contexts.
The whole words, contexts and tokens thing awaits further exploration. For example, in some recent scripts when I emit words into a block as data, I want them as symbols deliberately stripped of default bindings. I want that block data to have meaning applied by the receiving context - not baked in and not having to use Parse to do it, which also means some custom reduction and block rewriting techniques (reduce-if-bound otherwise leave-as-is, etc).
parsing-at was a rule generation function allowing a rebol expression to determine a parsing match.
E.g. this should succeed.
an-odd: parsing-at x [if attempt [odd? x/1] [next x]]
parse [3] an-odd
Looking "at the biggest issue to sort out in UPARSE"
A valuable exercise.
Umm.. taken literally that's seems limiting.
Taken more broadly as interpretation, evaluation of a tree, maintaining the context I referred to earlier, then yes.
Perhaps combinators can return the tree structure, if I understand right.
Maybe. A log that emits a bunch of parse actions that can be rebound and reduced or played back to build a tree or extract or whatever, or rebuild the original input.
So maybe this is relevant, maybe not, but this is how I'm processing CSV now - it's cute and I get a human readable log as part of the bargain.
>> c: {1,2,3^/4,5,6}
== "1,2,3^/4,5,6"
print mold s: scan-excel-text #"," c pipe collect-script
[
opn
itm "1"
itm "2"
itm "3"
eol
itm "4"
itm "5"
itm "6"
eol
cls
]
That bunch of instructions can be played or piped through some interpreter to yield a result specific to the interpreter - one will create a tabbed delimited file, another to build a bunch of block records, another to rebuild the original CSV, etc.
Maybe a parse trace log like that could be similarly evaluated in different ways - whether it's powerful to do so....I don't know.
[now going back to a considerable number of photographic assignments with imminent due dates...]