What Were APROPOS and PARSING-AT About?

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...]

1 Like

Under the new framework, this seems like COMBINATOR. Although right now, combinators don't let you choose the name for INPUT, they're all stylized to assume INPUT is the name.

We'll definitely have something like this, that you can use for making a rule that you reuse...or just for calling directly.

GET-GROUP! is looking like it's going to stay on track as a way of saying "evaluate this group and then splice the result into the parse stream". Since LOGIC! true means keep parsing (as does NULL), and LOGIC! false means stop parsing, this is useful for many cases.

You could always capture, and say:

[x: capturing rule, :(test x)]

And that gives you one way of doing things. If the rule fails you'll be rolled back to where you were before the capture. Though it's not letting you scan and move the output position arbitrarily.

Okay, thanks for reminding me what APROPOS was. Not particularly related to parsing, but it does relate to binding.

Ren-C continues to strive to be a substrate for exploring binding ideas...I did this little writeup to try and look at it from the big picture:

Binding Re-Examined From First Principles

The technical parts are trying to get better while staying functional. I'm not that worried about slowing things down if I can get at some answer that is right for some definition of right that lets you do cool things. I just feel historical Red and Rebol has only let you do broken things...