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
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 
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.
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...
I think what people want is to run old scripts without modification.
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
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
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.
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.
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
- 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.
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.
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.
It seems a line was drawn by creating bootstrap binaries in Dec 2018. Perhaps stablize on those?
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.
Veto.
A choice to write scripts to that version of Ren-C will not receive support or bugfixes from me. Which would make it a difficult choice. It also lacks TLS 1.2.
This is partially my fault, by being unable to satisfy a finished-enough subset of the language to call "Beta/One" where experimental features are labeled thusly and be satisfied.
One has to realize though just how many concerns are in play. And it doesn't just involve the in-language stuff you see, or even the in-core stuff almost no one will ever see...but also the inter-language APIs which an in-between number of people to see.
I know it may be hard for the usermode folks to understand just how patently bad libRed is by comparison to the mechanics of libRebol. I don't know if I can get you to take my word for how important getting all this stuff right is, but it is important...
This is partially everyone else's fault, by seeming more excited (rightly or wrongly) in seeing what we can do with the web.
But I was won over as a convert. This is what reshaped my thought that a Ren-C-powered Redbol--which has desktop and browser availability--is the only answer for those who don't want to participate in the experimental portion of the "grand experiment". At least for the near term.
To make Redbol code work as expected, lib/append (or whatever) will have to act like Redbol append. So the underlying Ren-C lib of primitives will have to be lib3 or something. Conveniences in a module header for saying which Ren-C-isms you would like might be added as well.
This means you'll have access to those Ren-C-isms you find worth it. We can even bring in "approved" sets of experiments for the ones people consider truly indispensible, and honor backwards compatibility for those:
Rebol [
Title: "How we might name experimental sets"
Experiments: [17-Jan-2020 specialize adapt]
]
So if SPECIALIZE and ADAPT haven't been committed to in terms of their interfaces, then you could name a date and then the interested parties could build adapters for after when those words have been retaken for new interfaces.
So Redbol is the only option for "documented and stable", and it does exist in a form today.
It's not terribly pretty, and it contains a bunch of archaic code from what used to be called <r3-legacy>. A lot of that could be written much better with modern Ren-C.
https://github.com/metaeducation/ren-c/blob/master/scripts/redbol.reb
I mentioned I'd gotten a simple PDF out of Gabriele's PDF maker. Redbol is used to build hostilefork.com via a static site generator. With more people willing to hack on Redbol and take it on--with a GitHub issue database of its own and getting it to run through Red's test suite--it could advance.
Anyway, I've gone from seeing building old Rebol2 compatibility as being a chore to thinking of it as a demonstration of the true power of Ren-C and what makes it possible for a Rebol-like language to bend to what you want it to be. What worries me are the technical challenges of binding and such that have yet to be solved--modules never really worked.
The other option is commit to the experiment, roll with the punches, write tests and tell me where your source is and I help you keep it up to date. I can only do this for a limited number of projects which pretty much have to be of interest to a wide audience--certainly wider than just the author themselves.