Library for embedding a Rebol interpreter into C codebases
C Rebol C++ Clojure HTML CMake
Clone or download
Pull request Compare This branch is 3988 commits ahead, 14 commits behind rebolsource:master.
hostilefork Always have one stack frame in effect
In order to avoid conditional checking for null of the previous frame,
this makes sure there is at least one "dummy" frame in effect at the
bottom of the stack.  It also consolidates the dummy ACTION! used for
that frame's phase with two other instances in which a placeholder
action was required in the code.

Truly being able to use the top frame in all operations and know it
was not null...e.g. in API operations, required some reodering of the
startup process.  This process needs review--especially in light of
threading or isolates.  However, minimal changes were made just to get
the necessary dependencies for this commit.

One result of this is that there is always a context to which to tie
Alloc_Value() allocations.
Latest commit bed82bd Jul 16, 2018

Ren-C Logo


Build Status

Ren-C is an interim fork of the Apache 2.0 open-sourced Rebol codebase.

The goal of the project isn't to be a "new" language, but to solve many of the outstanding design problems historically present in Rebol. Several of these problems have been solved already. For progress and notes on these issues, a Trello board is semi-frequently updated to reflect a summary of important changes.

Rather than be a brand or product in its own right, this project intends to provide smooth APIs for embedding an interpreter in C programs...hopefully eventually rebol.exe itself.

One of these APIs (libRebol) is "user-friendly" to C programmers, allowing them to avoid the low-level concerns of the interpreter and just run snippets of code mixed with values, as easily as:

int x = 1020;
REBVAL *negate_function = rebRun("get 'negate", END);

rebRun("print [", rebInteger(x), "+ (2 *", rebEval(negate_function), "3)]", END);

The other API (libRebolCore) would offer nearly the full range of power that is internally offered to the core. It would allow one to pick apart value cells and write extensions that are equally efficient to built-in natives like REDUCE. This more heavyweight API would be used by extensions for which performance is critical.

The current way to explore the new features of Ren-C is using the r3 console. It is significantly enhanced from the open-sourced R3-Alpha...with much of its behavior coming from userspace Rebol code (as opposed to hardcoded C). In addition to multi-line editing and UTF-8 support, it can be "skinned" and configured in various ways, and non-C programmers can easily help contribute to enhancing it.

A C++ binding is also available, and for those interested in a novel application of this code, they might want to see the experimental console based on it and Qt: Ren Garden.

In doing this work, the hope is to provide an artifact that would rally common usage between the mainline builds, community builds, and those made by Atronix Engineering and Saphirion AG.


To promote the Rebol community's participation in public forums, development discussion for Ren-C generally takes place in the Rebol* StackOverflow Chat.

There is a Discourse forum available for more long-form discussion.

It is also possible to contact the developers through the Ren-C GitHub Issues page. This should be limited to questions regarding the Ren-C builds specifically, as overall language design wishes and debates are kept in the rebol-issues repository of Rebol's GitHub.


As a design goal, compiling Ren-C depends on very little beyond ANSI C89. Attempts to reign in compiler dependencies have been a large amount of work, and it still supports a number of older platforms. However, if it is compiled with a C++ compiler then there is significantly more static analysis at build time, to catch errors.

The open-sourced R3-Alpha was based on a build process that depended on GNU make, and needed an existing R3-Alpha executable in order to generate that makefile (as well as other generated supporting C files). This process was recently replaced with a Rebol-only building solution (%rebmake.r) which requires no other tool, and can spawn compilation processes itself. Yet it still can generate GNU makefiles or a Visual Studio Solution if desired.

While this process works, it introduced considerable complexity...and needs a relatively modern Ren-C build to bootstrap--as opposed to a historical R3-Alpha. For the moment, some usable binaries are committed into the %make/ directory for 32/64-bit platforms on Linux/Mac/Windows.

Building is a matter of picking a config out of the %make/configs/ directory, or just taking the defaults. Options may be overridden on the command line of %make.r (which is a client of Rebmake):

r3-make make.r CONFIG=configs/vs2017-x64.r DEBUG=asserts

That would use the Windows r3-make tool to build a project for Visual Studio 2017.

(Because other priorities have taken the focus away from improvements to this build process, it would be strongly desirable if community member(s) could get involved to help streamline and document it! Since it's now all written in Rebol, that should be more possible.)