The Fate of Redbol Emulation In A Mostly Unbound World

So on top of all the other complications, the situation just got a lot more... sticky

Big Alien Proposal 🛸 "/WORD" Runs Functions - #13 by hostilefork

The writing is on the wall:

Emulating Rebol2/Red is not important enough in the near term to make sacrifices that impede progress.

Redbol Was Not A Waste Of Time

From its modest start as a small script in 2018 to its more expansive emulation circa 2024, Redbol has informed and tested the design of Ren-C.

It legitimately ran historical scripts, even the complex %pdf-maker.r at one point. (Though later I focused the attention and CI handling on my own historical scripts, e.g. the original USCII and the original Whitespace Dialect)

But it required kludges in the evaluator--very ugly ones--to still support obj/subobj/accessor/refinement in a world where Ren-C required obj.subobj.accessor/refinement. The code handling that is a blight, and causes undue burden on switching this to obj.subobj/accessor:refinement while still handling the original form. What should be emergently elegant code following the new more coherent model would be torturous and correspondingly buggy.

Those kludges need to be cut out. And Redbol emulation will die.

What About Bootstrap?

The bootstrap executable doesn't have generalized TUPLE!. And it's not going to get it! :face_with_raised_eyebrow: That's simply too deep and far reaching a change to apply to sources circa 2018.

So you might think the kludges need to remain, since the bootstrap EXE will only ever understand obj/subobj/accessor/refinement... until the deep future where we're confident enough to bootstrap to a pure virtual binding EXE. Which would mean it needs to be not just robust, but faster too, otherwise my development will be slowed down. Realistically I would not schedule Pure Virtual Binding Bootstrap until at least 2026.

(If that seems like slow progress, it is not uncommon for much more rigorous projects with orders of magnitude more people to use "LTS" releases for their bootstrap.)

I Have A Plan! :scientist:

I'm just going to hack up the bootstrap executable's scanner.

ren-c-boot>> transcode "obj.subobj/accessor:refinement"
== [obj/subobj/accessor/refinement]

Then all the code that needs to run in both the bootstrap executable and the current executable can be written to the new style.

It's "trivial"cough to implement, it works, and it means the kludges for supporting all-path formats can be cut out of the modern executable.

But Redbol Will Be Dead...For Now :skull_and_crossbones:

Bringing it back to life and letting obj/subobj/accessor/refinement act in accordance with history will require parameterized evaluation. This would be kind of like how UPARSE lets you use a collection of COMBINATORs picked according to the type it encounters, you'd have EVALUATORs that did the same.

So Redbol would have in its evaluation map an entry for PATH!. It would map to something that would rewrite that path as the right sequence of PATH!/CHAIN!/TUPLE! (or perhaps just do the interpretation itself).

That PATH! evaluator would also have to notice when its first element was a CHAIN! that started with BLANK!. So :a/b would need to be rewritten as :a.b (or again, just directly evaluate...if these EVALUATORs are native code then so long as they've already done the analysis to know what a correct rewrite would be, they might as well just do the implied operations as they go).

The New Redbol Probably Won't Be Written By Me

I can imagine laying the foundations of parameterized evaluators, and using some Redbol behaviors as a demo. But I can't imagine myself feeling compelled to go deep into actually completing the whole emulation initiative.

So if it ever happens, it would be the pursuit of some enthusiasts (or enthusiast AI) who thinks it would be novel to run Rebol2 or Red code inside of Ren-C.

I don't think there are going to be any Rebol2 modules that will actually be relevant or useful in a practical sense to leverage in Ren-C. So it's only fun, nostalgia, and a tech demo.

We Can Still Leverage Tests (PARSE2, APPLY2...)

Being able to twist UPARSE so it acts like Rebol2 and Red was a great demo. And we can still demo it running Rebol2 or Red tests. It's just that anything that's not related to parsing needs to be updated.

; hypothetical Rebol2 COPY test in PARSE
(
    obj: make object! [what: <tag>]
    all [
        parse [{"} b <tag>] compose [text! copy result thru (obj/what)]
        result = [b <tag>]
    ]
)

We could keep things like that, and say parse: get $parse2 but just change the little bits that need changing:

(
    obj: {what: <tag>}
    all [
        parse [-{"}- b <tag>] compose [text! copy result thru (obj.what)]
        result = [b <tag>]
    ] 
)

So that's the way the tides are flowing at the moment. I'm sad to see Redbol get sidelined, but it's far outweighed by my positive feelings about the direction of the new designs.

It's a strange delicate balancing act with tons of spinning plates in the air to come up with strategies for these changes!

1 Like