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
<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
%redbol.red, 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.