Requirements List for the Redbol Compatibility Module


There needs to be some candidate Rebol2/Red/R3-Alpha-ish codebase to be the guinea pig for the “Redbol” emulation module. I’m going to sacrifice my Draem blog generator to stay in the world of Redbol compatibility. It doesn’t make me tremendously happy to hold it back–but I’ve already been holding it back for the purposes of testing <r3-legacy>. So this just means a little bit more holding back.

That will require backporting it to Rebol2. Then I will twist up <r3-legacy> until it can run it also. And if I haven’t strangled myself with my own tongue by then, I will see what I can do to run it under Red. Then rename <r3-legacy> to <redbol> and try and get the module-based approach going.

It’s not terribly ambitious code, though it does need Markdown processing. Hopefully that’s already been addressed in Red or Rebol2 somewhere.


In this sense I’m using the term “Redbol” to mean “roughly the language agreed upon represented by Rebol2 and Red”. If Red and Rebol2 agree on something, and R3-Alpha made another choice, it doesn’t seem to me to make much sense for this compatibility layer to pick R3-Alpha’s choice out of principle–even if it’s arguably a better choice. The point is emulation, not arguing.

This needs to be done with actual modules, isolating the behavior so that a Redbol module can be called from a Ren-C module, and vice-versa. How things have been done so far with <r3-legacy> can’t handle that. It just mucks up the user context.

Thoughts on baseline?

Rebol2 was skinned to incorporate many of R3-Alpha features via something known as “R2/Forward”. Since we’re not necessarily looking at exact compatibility with any of Rebol2/Red/R3-Alpha, it’s reasonable to say that someone using the Redbol emulation would likely have a few little stubs loaded.

(So to run a Redbol codebase in Rebol2 you’d use %redbol.r, to run it in Red you’d use, and in Ren-C you’d tag your module as Depends: <redbol> or whatever the way that winds up working. I don’t think a %redbol.r3 would be used by anyone, and things like the indexing are impractical to bend from within an R3-Alpha binary.)

So given that, does anyone have any “known” lists of tweaks they know each would need? What did Red change from Rebol2 that’s favorable, unfavorable? Most of what I’ve got going on compatibility so far is code in the %mezz-legacy.r, so that’s going to be the starting point for Ren-C’s <redbol>…the question is just what more will be needed than that.

My main intention is just to get a proof of concept going, and then those interested can see what’s involved and hack on it as they notice things it could do more compatibly. I’m not going to spearhead any protracted development process for it.

But if someone has a relatively simple Rebol2 script and wants to put in a bit of elbow grease to see it run under emulation, maybe you could post about it here and explain what challenges (if any) there would be.

Strict Equality, Lax Equality, Equivalence, Sameness: IS and =

I suspect most of us have already converted our Rebol2 scripts to ren-c. But, @rgchris has a suite of r2 scripts.

But how important is a Redbol module? More important than getting the Emscripten working properly?


When it happens exactly is up for grabs. But I mentioned what’s making it pressing to figure out how to do it is going ahead with Big Incompatible Changes, such as the is and =.

The same mechanic behind it will be needed to keep a stable shim for Beta/One going as well. <r3-legacy>'s method isn’t going to cut it.

The most practical place for me to start testing a means for this is with my blog code, so that is the plan. I’m just offering that people can put in thoughts if they have them.


There’s the red.r script :rofl:


I don’t know what that is…so link if it’s relevant.

The only existing compatibility efforts I know about are Rebol2’s r2-forward and Ren-C’s <r3-legacy>. And I don’t know if there’s stuff in r2-forward that people consider to be “not Rebol2” or if all of that has basically won support and made it into Red. That would be a good example of something to know about…

Point just being that basically I plan to pull <r3-legacy> out soon and start on making redbol.reb something you can use. One way I’m thinking it will work is that if script headers start with Red [...] it will be picked up automatically (e.g. from the module lib). But if there’s another syntax people know, such as requiring a version, and what string should be in that version…that would be helpful.


I believe you ported the rebol2 red-lang script to r3 before.


I have to agree. My first reaction to this proposal was to wonder if this effort would be a distraction from more important goals. To me, attempting to make legacy (or Red) code/scripts compatible with Ren-C would be a “nice to have” but might ultimately be thankless, where some people have overly high expectations and gripe about issues and edge-cases.


It is a critical feature to be able to “skin” the environment via the module system; in a way that doesn’t interfere with other modules.

That’s never really been realized. While modules did have an ‘isolate’ option, that isolation gave each module a copy of the lib as it was at startup. (But not necessarily, given that lib was never protected from modifications…) Choosing alternate libs wasn’t covered in a clear way.

“Making up a skin” has the risk of being an arbitrary thought experiment.

Rebol2/Red already exist, so they aren’t just thought experiments. A codebase for <r3-legacy> exists (that I would like to excise from the main r3.exe).

might ultimately be thankless, where some people have overly high expectations and gripe about issues and edge-cases.

I’m certainly not thinking of personally making any big effort to please anyone adversarial.

The pleasing aspect in general will be “hey, make modules work and be useful”. But I thought I’d give people a chance to put in thoughts of what they might like to get out of what is going to become of <r3-legacy>, now that it is being excised and no longer trying to preserve R3-Alpha semantics.

Also by posting I just wanted to make sure people know that this is the split line when it comes to things like %fOo !== <FoO>. I do want to make sure Ren-C is a superset in terms of what it can do…but what comes in the box should be as good as it can be, free of junk.


Thanks Brian.
I’m in favor of modules, it was the compatibility aspect which gave me pause.