Could Ren-C and Red Interoperate (and if so, *should* they?)

When this year can we expect to see full "message passing" inter-operability between Ren-C and Red?

The very basics - MOLD and SAVE are almost in place.

The "binary" equivalent with some form of compatible REBBIN is surely not that hard to agree between the two sets of developers.

Fuller, fluid, message passing - for example the seamless invoking of functions and continuations within a running instance of the other language would be an important demonstration of the REBOL cousins' languages abilities to do what they have stated is a desired characteristic of their respective dialects of REBOL.

This would also harness the strengths of both dialects - for each has been focused these last few years on different arenas. Together, they have the makings of a formidable whole.

The term "Ren" (REadable Notation) was an initiative from--I believe--Gregg Irwin and Rebolek, where the idea was to standardize notations between Rebol and Red in a similar way to how JSON was standardized... then allowing other languages (like Python or JavaScript) be able to read the messages as well:

Since that was in the air at the time...and my fork wouldn't/couldn't be called Rebol(tm), the idea was to embrace the idea and call itself "Ren-C" to be the C implementation of that data structure.

That was long ago. And you won't hear the term "Ren" thrown around by Red much anymore. And with consensus designs between the projects out the window, it's clear Ren-C is overdue for a name change. (But you don't get a second chance to make a first impression, so no point in announcing a new name unless there's a bigger announcement to accompany it.)

...point of the above being...

The very basics - MOLD and SAVE are almost in place.

...I don't know how close we're going to get on this.

Ren-C hopes to be a kind-of-superset. So far, the superset is an emulation layer I call "Redbol", and that emulation becomes more difficult as we go along. (Though I have some ideas.)

The "binary" equivalent with some form of compatible REBBIN is surely not that hard to agree between the two sets of developers.

I'd say it's very hard if redbin attempts to capture objects and (I think?) binding. Binding is going to be very different, as summarized in:

Rebol And Scopes: Well, Why Not?

I understand feeling there must be some teachable moment to be found on what essence of shared concepts and syntax both Ren-C and Red find so critical as to not throw out.

Despite understanding someone having the feeling that should be true... the reality is that interoperability is likely to get worse and not better. Less will work in the future than works today.

It may be a subset of what could be called "Ren" could be read and written by both. Important to note is that JSON is typically parsed and not "LOAD"-ed as code even by JavaScript, so similar premises could apply there.

1 Like

It seems somewhat of a wasted opportunity that the language has drifted so far from its initiating vision.

The earliest copy of the home page on is from May 1998. It contains the sentence:

The Relative Expression-Based Object Language (REBOL, pronounced "reh-bul") is the language of inter-communications. It supports both the exchange and interpretation of information, and offers an easy way to share information and programs between people, applications, and computers.

And now - nearly 25 years on - we can share neither information nor programs between even closely-related descendants of that initial release.

Such is progress.

Rebol had a lot of disparate elements, and people latched onto different ones... based on which parts they wanted to believe were the most important.

To some people, the lack of dependencies and not needing an install program was key.

To some people, it was very important that Rebol was cross-platform so they could deploy the same programs to customers on Windows/Linux/Mac.

To some people, they couldn't write a GUI on modern systems with other tools to save their life. So having a way to get a button on the screen with minimal code and not having to figure out what graphics libraries to pick for their language was key. (These are people who could have used Visual Basic, but felt it was just getting too bloated and unpredictable, and found they liked other aspects of Rebol better.)

To some people--myself included--the notion of having a language you could really bend to whatever task you were doing via dialecting was the main draw.

Anyway: point being there are a lot of ideas in it, and wound up with a lot of wishful thinking and projection being put on an artifact that was ultimately too simple and under-designed to live up to the hype. Carl called it his "grand experiment"...and I think of the usage of "experiment" in the sense of "this might not work". Some things have worked out better than one would expect, and others have shown to be fairly intractable in the medium.

Data representation is tough, because the structure of data is often connected in weird ways...which you need graph databases to do correctly. Trying to represent graph structures in text is a very narrow and limited idea.

I think that JSON took most of the low-hanging fruit of what Rebol's base format could have offered in data exchange, and YAML has actually stepped in for a lot of places where JSON isn't a fit and shown to be better still.

The fact that Rebol did not set up a clear way to lexically exchange objects left it in a tough situation where I think it often works out to be inferior to JSON for most tasks...despite having some superficial niceties of knowing how to--say--exchange dates. (More often than not, people wind up needing ISO 8601 dates anyway, which shows that Rebol's peculiarities aren't always all they're cracked up to be when working in a world that Rebol is not a standard.)

Carl seems to have wanted to rethink the object issue--to the point of sacrificing braced strings--see his ASON:

Carl's New Projects (?) AltScript, AltOS

(I considered this, but ultimately decided I thought the braced strings were too foundational to what makes Rebol we'll have to address that weakness some other way.)

As a thought experiment it would be great to see if Rebol-to-Rebol data exchanges could have a start-to-finish story where the whole experience is better than JSON, without this:

I've written some thoughts here and there about directions I think things might be able to go in the representation:

BLOCK! and OBJECT! Parity in Pathing/Picking