Requirements List for the Redbol Compatibility Module

Domains Redbol
1

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.

"Redbol"

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.

2

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?

1 Like
3

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.

4

There's the red.r script :rofl:

5

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.

6

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

7

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.

8

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.

9

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

10

With the web console, I think that Redbol has a renewed purpose. Not a goal of running existing scripts on someone's desktop--but letting people curious about the web console see it working and not think "it's broken" as their first impression. :-/

I'm wondering how far to take it, though. If they get:

>> none
== _

...will it be good enough? It may be mostly runtime compatible (and more honest than == none, which looks like a WORD!). But is it worth it to have some mold-mode compatibility to take care of any of the most common complaints?

Not sure yet...

11

I think what people want is to run old scripts without modification.

12

I am interested in this. I'd be curious how possible it'd be to have Ren-C use this as an alternative evaluation model.

I'm not necessarily interested in strict compatibility with Rebol 2—I'd look to incorporate some of the more advanced capabilities of Rebol 3 and Ren-C (ports, zip, etc.) with a view to having a stable platform. Actually, my evaluation model would be closer to Ren-C circa. early 2018.

I think this would address some of my frustrations with the current direction and offer a path to modernity to others that are looking to move on from Rebol 2 while staying with the C-based ecosystem without compromising Ren-C as an experimentation platform.

1 Like
13

It's a bit hard for me to swallow that the best near-term path is to leverage the existing documentation (and any momentum Red has picked up or will--they are soliciting people to make infographics, for instance.)

But investing in Redbol does push aggressively on Ren-C mechanics. It's hard. So when features come along like being able to use AUGMENT to add /DEFAULT back into SWITCH without having to rewrite it...I don't feel that put out.

Documenting Ren-C and developing it simultaneously is simply too much work. @jhgorse was asking me about tutorials and I pointed him to @Brett's old PARSE tutorial that had been updated for Rebol3. But then Ren-C PARSE was returning a position and not true or false, so that throws people off...then they have to learn about DID to convert to a logic :-/

In-browser interactive tutorial is still the way I want to teach Ren-C design. So that plan remains unchanged. I'll try and go back over the Trello and sync it one of these days.

1 Like
14

Ren-C changes are substantial and ongoing with no prospective endpoint. I'd like a conservative path that benefits existing developers—a replacement for Rebol 2 that can take advantage of new architecture, and available soon.

I'm resolved that even if it be conservative, it will not be fully compatible with existing documentation, just familiar enough that there is a path to migration from Rebol 2 that doesn't involve wholesale changes. One that is performant and reliable.

This does not mean I am not supportive of the experimental nature of Ren-C, it just reflects a pressing need for those that currently use Rebol in production environments and cannot afford to wait for Red to mature (if, by your critique, that is even likely), for Ren-C to be framed and stable, or for Rebol 2 to simply stop working.

Prior conversions of scripts from Rebol 2 to earlier Ren-C lead me to believe this is a viable path.

15

I have shifted my view to where I think this is the most likely viable path (but I am subject to the usual limits of being human.)

As I've demonstrated through e.g. solving ODBC issues, when people engage I do put in the hours. If you want it to happen it can happen.

I dunno. jury is out on that. I harassed hiiamboris the other night. It would sure be easier if we had everyone on the same page, but we don't. So.

16

I don't anticipate this being an overwhelming diversion—I feel like most of the work is already done (it kind of depends whether there's a willingness to slap 'done' on ports for this purpose).

I do want it to happen. I want to invest as much time as needed to get it done and then move on. I will likely need to raise a modest amount of funds to make that possible though, that's the biggest caveat to contributing my own time.

Here's where I think it benefits Ren-C:

  • It's a conservative path for the small but I'd say significant** handful of Rebol 2 developers to adopt and test the Ren-C codebase
  • Establishes a new language baseline that is closer to Ren-C
  • Reassurance that there is a future and that Rebol 2 (I am holding off upgrading MacOS in fear of losing Rebol 2)

** from the perspective of providing higher grade of sample code that is production-tested

My priorities are:

  • Feature-for-feature parity with Rebol 2 Core (that is to say, it should at least be able to do everything that Rebol/Core 2 can), plus new features (zip support, uuid, tls, etc.)
  • Core language based on Ren-C of around early last year—I believe Ren-C significantly diverged from Rebol 3 Alpha around that time: before that point, porting code was largely an exercise in refactoring
  • Identify some language changes that would make the cut—for me this would include:
    • Parse returning a position
    • Many of the naming changes, e.g.: text!, *-of family, blank!, void!
    • Issue! as a string :slight_smile:
    • spaced/unspaced
    • I'm really not sure about sticking with blank-based flow, I get the null concept, but the overriding priority is that it should be relatively trivial to port old codebases
    • Similarly, I may be resigned that lit-word! persists in this world, much as I'd like generalised quoting
  • Optimised (I want my Tiny Elvis)
  • A target completion date

This is a non-exhaustive list—I'm spitballing somewhat.

I'm also not advocating a return to the dark ages, just drawing a line under the what we'd understood to be 'Rebol 3'. Ren-C would still represent the next generation with all the cool reality-bending stuff.

17

I'm going to make a post regarding my concept, now, given what is going on.

We had a setback--and I think it might not be the last setback--it seems the Wasm guys are still figuring their own selves out.

18

I haven't been disinterested—I just feel things are moving away from an aesthetic that I'm comfortable with, my concerns are not of much consequence, and to be productive at all I continue to live in Rebol 2 land. A pretty dispiriting state.

I'm keen (or desperate) to find some middle ground between where I am now, where I'd like to be, and where you're headed. Some waypoint in between this—'Rebol 3'—would I think help bridge the gap.

20

It seems a line was drawn by creating bootstrap binaries in Dec 2018. Perhaps stablize on those?

21

Sorry you would feel that. It's certainly not how I feel.

I don't really consider the mission to be broken if I can't get you to like the way I like to code. It's broken when you can't code the way you want to.

I realize there are little points like how you like to see things start with EITHER so you know up front an "else branch" is coming later, which would lead you to choose it over IF...ELSE. But I like having the freedom to choose--I mix and match. In fact, it's very helpful using EITHER if you want your truthy branch to be able to return NULL, as that is the signal that ELSE would trigger on.

And maybe it frustrates you if you have to read and absorb things I design if you think it has tics you dislike. The <*> being another example, but I think you have to study the alternatives to being able to somehow "tag" what points in a COMPOSE you want to substitute for. It's convoluted otherwise to COMPOSE things you wanted to contain GROUP!s:

r3-alpha>> compose [(quote (1 + 2)) (3 + 4) (quote (5 + 6))]
== [(1 + 2) 7 (5 + 6)]

ren-c>> compose [(the (1 + 2)) (3 + 4) (the (5 + 6))]
== [(1 + 2) 7 (5 + 6)]  ; same style, but THE is used for literal values vs. quoting

ren-c> compose <*> [(1 + 2) (<*> 3 + 4) (5 + 6)]
== [(1 + 2) 7 (5 + 6)]  ; alt. style, compelling w/more groups in block

ren-c> compose <b> compose <a> [
         (<b> print "phase B" 1 + 2) (3 + 4) (<a> print "phase A" 5 + 6)
     ]
phase A
phase B
== [3 (3 + 4) 11]  ; you can really make multiple phases clear

ren-c> compose % [(1 + 2) (% 3 + 4) (5 + 6)]
== [(1 + 2) 7 (5 + 6)]  ; FILE! is an option too

That's a case where if you don't like the new option you don't have to use it. I imagine you'd warm up to the option if you had more experience with it, and weren't stuck in a frustrating situation of it being the year 2020 and not having the Rebol tool you want and need. That frustration may be clouding your ability to learn and appreciate tools that you would really like if you had the time to absorb them.

There are other cases where change is imposed because I'm still trying to solve basic usability, and given that it's something you have to deal with whether you like or not I accept these decisions are fundamentally different. But I also don't feel there's much point in having come this far if you still have a tool that is brittle and bites noobs and experts alike. COMPOSE splicing blocks by default is something that makes it very difficult, and remembering COMPOSE/ONLY is hard -and- makes it hard to mix/match. So I like:

>> block: [a b c]
>> compose [(block) ((block))]
== [[a b c] a b c]

Something about this feels good and clean to me. But if you don't like it we really need to talk about it, because unlike COMPOSE <*> this is a mandate unless you redefine COMPOSE.

...which you can. This was finessed with something called a predicate, which runs over every group in the compose before ultimately composing it. The trick is that COMPOSE always splices blocks only...but the default predicate if you don't supply one is ENBLOCK. Just use an identity function instead:

>> compose: specialize 'lib/compose [
        predicate: func [x] [:x]  ; e.g. IDENTITY
   ]

>> block: [a b c]
>> compose [(block) ((block))]
== [a b c a b c]  ; (( )) means don't run predicate, so same as IDENTITY

So there really is kind of a fine line between mandates coming on high and things you are free to change on a dime in your project according to your tastes.

I want to give people the Rebol they want, but as my talk on Timelessness tried to stress, I am driven by solving that aspect. Red has more people working on the question of serving the historical Rebol audience--and if they can't do that after a decade or whatever--I'd be a fool to think that I could alone do that as well as meet MY goals...!

Hence the importance of perpetually weighing in on the discussions--the way people used to on CureCode or wherever--is high. If there's something blocking use of current Ren-C... even if it's an "aesthetic" block, I'll listen.