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
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.
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
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
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
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.)