As the Syllable project predicted many years ago, version 3 of the REBOL programming language has finally been open sourced, under the Apache 2 licence (screenshot on Syllable Desktop). Also, the alpha version of the high-level Red programming language, supporting Syllable Desktop, has been released, by now in version 0.3.1 (screenshot, demo program, video at the Science Park in Amsterdam).
The Syllable project has contributed a website running on Syllable Server where you can try REBOL without installing it. REBOL originally constituted Syllable’s main cross-platform strategy, but the project is now also free to use it in the Syllable base platform, which should not contain closed parts. So far, REBOL3 ran on Syllable Desktop using the Linux version of the interpreter library. Now its source code compiles natively on Syllable, and the project has integrated it in Syllable’s build system. To compile REBOL and start it, enter the following commands in the terminal. You need the latest version of Builder. On Syllable Desktop0.6.7, do:
build update build log package unregister Builder package register Builder build REBOL-Core--current build install REBOL-Core--current r3
On Syllable Server, install the newer Builder package. Then do:
s build update build log build get REBOL-Core--current
Install the binary version of REBOL3 in the
REBOL-Core--current/make/ subdirectory as
r3-make. Then from the parent directory again:
build REBOL-Core--current build install REBOL-Core--current r3
Syllable now has the choice between the interpreted REBOL language and the compiled Red language. The Syllable project has already contributed a bridge between them, that allows to write REBOL extensions in the Red/System language. Previously, REBOL3 extensions needed to be developed inC, which has proven unpopular. This currently requires a development branch of Red on Windows, but this will be extended to Syllable.
The high-level Red programming language compiles to the low-level Red/System language as an intermediate format before compiling it to native machine code. Red/System was already ported to Syllable, but more work was needed for Red. It requires Syllable0.6.7 for its POSIX
mmap support. Ready to run test programs are here (download, instructions) for all Red’s targets: Syllable, Linux x86, Linux ARM (screenshot on the Raspberry Pi, video on Hardware Freedom Day), Android, OS X and Windows.
The first Red screenshot shows Unicode support in the
hello demo. Greek characters are shown correctly, but the Chinese characters are missing because they are not available in the DejaVu font that Syllable uses.
On Syllable Server, the Linux x86 versions of the test programs should be used, in the “Linux” subdirectory of the testing repository. Red aims to have minimal dependencies on its host systems. For the simpler programs, this means that one binary is compatible across most of the many varieties of Linux distributions – an advantage over many other programming languages. Some of the test programs that use bindings to complex libraries don’t fare so well, because the libraries change rapidly over different versions in different Linux distributions. This goes even for the source code compatibility of the test programs: compiling them again on your Linux system doesn’t help. Red does table-based configuration of the source code instead of test-based configuration, so the compilation result is independent from the build system. This helps to make cross-compilation trivial. The test programs for all systems were cross-compiled on Linux with the included
build.r REBOL script.
On Windows, most of the test programs in the “MSDOS” subdirectory for the command prompt work better than the GUI versions in the “Windows” subdirectory, because they use command prompt output. The “MSDOS” subdirectory includes binaries for most of the libraries used by the test programs, so they don’t have to be installed separately.
Most of the OS X and Android versions of the test programs are untested, and several won’t run because the exact names of the needed libraries are incorrect. The project is interested in testers who can supply the correct library names and paths.
Originally, the plan for the Red compiler was to generate machine code immediately, while Red/System would only be used to write the low-level Red runtime library. This would have required multiple backends for each target system for both the Red and Red/System compilers. To save work, the Red compiler now has one backend generating Red/System code. Due to this decision, more effort has been spent to develop Red/System into a more capable language. While Red is in its alpha phase, Red/System is now quite mature. For example, it now supports namespaces, called contexts.
Also, the original plan for Red was to be a statically typed language with type inference, so it would have been fairly far removed from its inspiration, the dynamic, interpreted REBOL language. During implementation, it turned out that type inference could have disproportional costs, for example in terms of compilation time. Red will eventually include a JIT compiler, which should be fast, so it was decided to implement a hybrid static/dynamic typing system with optional typing. This brings Red quite close to the dynamic typing of REBOL, even though REBOL is an interpreter while Red is a compiler with a future JIT compiler. Currently, no optimisations are done, but future versions of Red will have ample room to implement optimisations through user-specified typing amended with automatic analyses.