Leveraging other programming languages to make a compiled RenC

One of the main things that RED has going for it is the idea that it can be compiled. But it's been a long time and RED doesn't really seem to be getting there all that fast. While looking around I found this language, "Ni", this guy made that was based on Rebol and Small talk but it's written in Nim.

Nim seems to have a lot of the advantages that Rebol has but it compiles to C and other languages.

So what's the point? Could whatever it is that Nim is doing be copied into RenC. It would be a big advantage if RenC/Rebol could be complied to C. Nim's idea to leverage all the mass of work done on C compilation is brilliant. Nim also has what is said by some to have a good garbage collection which can be tailored to different roles. Supposedly Nim also acts as a safer C by structuring the code emitted to the compiler to be safer C code. It looks very interesting. Another idea, which is blasphemous, is could Nim be used to write Rebol or RenC just like the guy who did Ni used Nim to write his language? If so the result would pick up all the advantages of Nim.

Not everyone would agree. I'd say that the demands of compilation stifle the dynamic aspects that make the higher level Rebol-languages potentially notable or interesting.

Trying to live up to that notability for a "personal language construction kit" is the essential goal, as I see it.

Compiling user programs wouldn't add any new functionality or open up any new platforms we can't be on already. It just means those programs would (presumably) run faster. But I don't really see performance as being the sticking point for use in the domains I think the language is appropriate for.

Ren-C already is playing the cards it plans to play, by compiling the interpreter with a C compiler. And with the TinyC compiler embedded, it can compile itself. Being careful about how all this is done means easier porting to new platforms, and cleverness is letting us bridge to crazy things like C# compiled to WASM in the browser.

But it will remain an interpreter. If you find a situation where performance is of extreme importance, you'd tackle the performance-sensitive parts by writing new natives for the interpreter. Which you could write in C (or Rust, or directly in WASM, or maybe JavaScript if that's what the underlying platform does faster than the interpreter). Even better would be in Red/System, or something like it.


In theory, that's fine, but a total rewrite is the kind of project that can kill software.

If we only talk about Nim, the multiplicity of garbage collectors only materializes with version 1.4 [1].

Stability is not yet at the rendezvous with no less than 6 regressions [2] just in the last minor version and still 34 others behind [3].

Other compilers exploit the not new idea of ‚Äč‚Äčtranspiling to C / C ++ such as the ofront compiler for Oberon-2 [4]. Also I will not be in love with it without first looking for the disadvantages.

So in my opinion RenC does not need these theoretical advantages that one would seek in others but to finish the maturation of the ideas specific to its paradigms, its mutation towards autonomy, to stabilize itself and to offer a complete and independent documentation of the Rebol 2/3 ecosystem.

Why complete and independent documentation? Because to make the way to RenC, it is to go through Rebol2, then Rebol3, then the myriad of pages of this forum and other. This reminds us of the differences in behavior between the dialects, which is mission impossible for ordinary people with such exploded information. Then frequent changes because for the moment it is experimental.

In short, what I expect from RenC is to take stock of its maturation and to distinguish between what is good enough to constitute a first official version, what must be reserved for later versions, which still lacks essential, then actually deliver this first version with full documentation, an official site, ready-to-use binaries. If RenC always remains in this dependence on Rebol, in this state of research, without concretization, it will be able to have all the advantages of the Earth, but it will have no more practical utility than a philosophical reflection whose principles can advantageously guide action but accomplish nothing in themselves.

If this materializes I will find that I was right to choose RenC over Red, that it is possible for the weary traveler to make stops on the way to the top of the mountain where Carl's vision is located, instead of believing in the false promises of Red's Golden Calf.

PS: I stigmatize. To be taken with a grain of salt ...

[1] https://nim-lang.org/blog/2020/12/08/introducing-orc.html
[2] https://nim-lang.org/blog/2020/12/01/version-142-released.html
[3] https://github.com/nim-lang/Nim/labels/Regression
[4] https://github.com/jtempl/ofront

1 Like

I definitely want to get there, but it's pretty much impossible to do alone.

Since I haven't had a dedicated working group to focus and knock off the issues one by one... I've instead been focusing on making it fast and pliable to bend to the decisions... whenever they're ready to be made.

With these recent commits coming as fast as the ideas can be articulated in forum posts, I'm showing that adaptability in action. So if @rgchris and others can stay involved and not wander off, there's a chance it can be done. "We have the technology..."

...and they have... half of an 80's cash register.... :stuck_out_tongue:

1 Like

So the bottleneck is more decision or design tradeoffs than code?

There are still fairly big fundamental holes in the model, where progress is chipped away slowly.

What drew my interest in Rebol initially was based on being puzzled about how it could work at all. I'd see something like:

rebol2>> foo: func [x y] [if x [do compose [1000 + (y)]]]

rebol2>> x: 5
rebol2>> y: 15

rebol2>> foo true [x + y]
== 1020  ; How did it know what I meant about which X and which Y?

When you can throw together simple examples like this so freely, and they generally seem to work (at first), it defies conventional wisdom...and you aren't sure exactly what the limits are.

Rejecting it out-of-hand because it isn't 100% built of typical formal principles could be like someone rejecting spreadsheets for the same kinds of reasons:

designer: "So you've got this grid of cells...the columns are marked with letters and the rows are marked with numbers. The user can fill data in a cell like a string or number. But if the cell starts with an equals sign, that can be a formula...referencing other cells. The program calculates the formulas and overlays the answer in the formula cells in the default view."

formalist: "That's a preposterous idea, that can be disproven with a simple example. What if cell A1 says it is =B1+50, and cell B1 says it is =A1+50. You'll get an infinite loop. Everyone knows you must separate your code from the data, and have the code checked for consistency in a compilation phase. This 'spreadsheet' is a waste of time, let me show you this pure functional language instead..."

But in terms of the mechanics, my opinion is that Rebol2 dead-ended rather quickly. The composability was so limited that you were rewriting the entire program and evaluation engine on nearly every change, because the language could not deliver. It was more of a "scriptable app" than a "language"...serving up a few features with a high dependence on Carl cracking open the C to deliver customizations that the small set of users needed that day.

(I'll point out that this way of thinking--that Rebol2 was an "app" tailored by its vendor to cater to the needs of certain users--manifested as a foray into wanting to turn Rebol Technologies into a consulting business. This concept is again being recycled by Red...with the idea of "we use it every day, it's a codebase we understand, so it's the lens through which we will solve your problem". But this doesn't really speak to the merits of the language for those who aren't years-deep in investing in its internal implementation--to the point it's the only thing they know how to edit anymore.)

The brokenness of returns was an early example of "unfit for purpose"...and it's something Ren-C addresses. (Here's a link to the point in a video where I explain definitional returns, and if you watch that whole video for context it hits a lot of points of the progress so far on various issues).

ren-c>> unless: function [cond block] [if not cond (block)]

ren-c>> bar: function [x] [unless x = 10 [return "not 10"] return "it's 10!"]

ren-c>> bar 20
== "not 10"  ; right answer (Rebol2, Red, R3-Alpha say "it's 10")

Some things like this need to be gotten right, otherwise people might as well use Red and accept that the flaws are so intrinsic to their design that it's going to be broken forever. (I can't serve the audience who will accept broken forever as an answer, because I'll never be able to compete with the rate at which garbage can be written.)

There are still more of these questions, where the mechanical issue underlying it is so basic that it would impact every piece of code written. There's no point in having people write a lot of deployment code if the rug is going to be yanked out from under them later.

But decisions will have to be made at some point on saying "that's as good as this version is going to be". What I want the first audience to be is code golfers, as a way of bringing in other ambitious designers to the project to contribute to the open areas before things are fully firmed up. Moving on to at least that phase has to happen somewhat soon.

I did not know the flaws where so fundamental. You example is clear. Maybe I didn't understand the situation. It really makes me think that you have to take stock of what RenC can and cannot do to assess your abilities and know where you are on the road to coherent language without huge pants. Synthesizing this allows everyone to set clear objectives to achieve the goal otherwise the work is atomized. Do you have to have a clear understanding of this list of blockages? Maybe on trello?

I am not a code golfer it must be said and, for the time being, I have given up doing the Rebol2 => Rebol3 => RenC apprenticeship because I have other OpenSource development projects that I am already busy with. I will be able to help to a certain extent but obviously I cannot give my opinion on design decisions when I do not practice the language. I see all your great posts go by and I can't reply. It's really frustrating.

I do not know. Maybe you expect too much from others to make the right decisions. I'm sure you're quite capable of slicing and writing the code. You have both abilities, it's great but also need support.

For reasons of either self-delusion or charlatanism, you won't hear it discussed many places besides here.

Here's another one from history: historical Rebol achieves binding by hiding a pointer inside a WORD!, that identifies the specific context OBJECT! that instance points to. So if you write:

 >> base: make object! [
     x: 10
     x-plus-20: does [x + 20]

 >> derived: make base [x: 30]

 >> base/x-plus-20
 == 30

 >> derived/x-plus-20
 == 50

You now have two objects. But the X in does [x + 20] points to BASE's X. How can DERIVED override this to find its X?

Historical Rebol's answer is that the MAKE OBJECT! for DERIVED does a deep copy of all the function bodies in the base object. If it has 20 methods, each with 20 BLOCK!s in it, then each object instance has to copy all these blocks. There are a number of reasons this is unsettling...in terms of semantics as well as efficiency. It's another issue Red doesn't talk about.

Ren-C addresses it with "derived binding"; copies are not needed. Which means this test runs reasonably quickly ...

Most of my "maximum concern" revolves around these topics:

These are the areas where the answers impact basically every program written, and where I kind of "just don't know, yet". I haven't come up with clever ways to mitigate risk with limited decisions yet.

Glad you can skim them. I think that maybe if you just kind of do as others do and keep tabs now and again, you'll be able to see when development hits a moment that you might be able to use it practically.

Maybe the most useful thing to carry away is just to save yourself some time on Red. I don't really mind people spinning their wheels over there long enough to get enough experience to see the flaws...at which point they might come out of it ready for the answers Ren-C provides (some working today, hopefully more tomorrow).

I what think Carl of all these blocking point ? He no longer intervenes because he has no idea how to solve them?

Can't speak for him. But I imagine he's probably more ready to accept Rebol as having its limits, and live without things that it doesn't do. He does embedded code now, and C is better there.

He's written that the bigger battle is against the "mindless" creep that's creating chaos and disempowerment everywhere in tech.

Whether that's digital TV: http://www.rebol.com/cgi-bin/blog.r?view=0411
...or your package manager: http://www.rebol.com/article/0497.html

So it's not so much "the solution is an .EXE of this language". Rather: "the kind of thinking by which this .EXE was produced shows how you might solve bigger problems with less...so use it as a model when evaluating other solutions."

And it inspired JSON as opposed to seeing the XML cancer spread any further than it did. Some would say in that way, Rebol probably already did its job. :man_shrugging:

1 Like

Ok, his interest shifted. I think the problem is rooted in the lie of evolutionism. More sophisticated technology does not change human nature but tests its limits. After that it is a question of knowing how to renounce the impossible and unatural.

Rebol remains valid. We can come up with a simple language, if the objectives are realistic. Do you see a solution to these 5 points?

The posts are mostly up to date on where these stand. I have some ideas on each; things percolate in the back of my mind. I've not written any of them off as not being able to have a "plausible response" (which I'd distinguish from saying things are necessarily "solved").

There are no guarantees in any of this. If you just stop and look at something like the source code for IF, you see this germ of an idea...where everything is built out of little imperative parts where the control constructs have no more power than you do, and there's a threshold of complexity you don't want the implementation moving past or it ruins the appeal. There's nothing pre-ordained in the stars that such a premise will result in anything besides a Turing Tarpit:

"Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy."

But I've seen enough interesting in it to make it feel worthwhile to keep looking at. Enough is different about it that it is truly "its own artistic medium" (2008):

What does it mean for a language to be a truly new medium, as opposed to a variation on a theme? That's rather debatable. A language I have been looking at lately is called "Rebol", and its advocates believe it to be a unique new medium. This is despite the fact that on first glance, it is an incredibly small box of crayons with a special color or two added, and lots of "ugly" colors taken out.

Yet to them it's also not like any other language that already exists. So if it were a product being introduced at Toys R Us, it wouldn't be a LEGO set with square plug-knobs instead of round ones....nor would it be finger paint that was merely a little stickier or a little easier to clean up. Beyond it's new-ness, its champions say it also has the property of good-ness: a hopeful new way to build fun art.

The fact that progress is slow on hard problems isn't that worrisome to me, so long as I keep finding new novel patterns you won't see anywhere else. It might look from the outside to some like "major" new features aren't happening, but they are, and so long as they are I stay interested. But nothing happens overnight...and if it ever seems like it does, that's just neglecting all the parts that had to click into place to make that change come.