red / red

Red is a next-generation programming language strongly inspired by Rebol, but with a broader field of usage thanks to its native-code compiler, from system programming to high-level scripting and cross-platform reactive GUI, while providing modern support for concurrency, all in a zero-install, zero-config, single ~1MB file!

Red Programming Language

Red is a programming language strongly inspired by Rebol, but with a broader field of usage thanks to its native-code compiler, from system programming to high-level scripting, while providing modern support for concurrency and multi-core CPUs.

Red tackles the software building complexity using a DSL-oriented approach (we call them dialects) . The following dialects are built-in:

• Red/System: a C-level system programming language compiled to native code
• Parse: a powerful PEG parser
• VID: a simple GUI layout creation dialect
• Draw: a vector 2D drawing dialect
• Rich-text: a rich-text description dialect

Red has its own complete cross-platform toolchain, featuring an encapper, a native compiler, an interpreter, and a linker, not depending on any third-party library, except for a Rebol2 interpreter, required during the alpha stage. Once 1.0 is reached, Red will be self-hosted. Currently, Red is still at alpha stage and 32-bit only.

Red's main features are:

• Human-friendly syntax
• Homoiconic (Red is its own meta-language and own data-format)
• Functional, imperative, reactive and symbolic programming
• Prototype-based object support
• Multi-typing
• Powerful pattern-matching Macros system
• Rich set of built-in datatypes (50+)
• Both statically and JIT-compiled(*) to native code
• Cross-compilation done right
• Produces executables of less than 1MB, with no dependencies
• Concurrency and parallelism strong support (actors, parallel collections)(*)
• Low-level system programming abilities through the built-in Red/System DSL
• Powerful PEG parser DSL built-in
• Fast and compacting Garbage Collector
• Instrumentation built-in for the interpreter, lexer and parser.
• Cross-platform native GUI system, with a UI layout DSL and a drawing DSL
• Bridging to the JVM
• High-level scripting and REPL GUI and CLI consoles included
• Visual Studio Code plugin, with many helpful features
• Highly embeddable
• Low memory footprint
• Single-file (~1MB) contains whole toolchain, full standard library and REPL (**)
• No install, no setup
• Fun guaranteed!

(*) Not implemented yet. (**) Temporarily split in two binaries

More information at red-lang.org.

Running the Red REPL

Download a GUI or CLI console binary suitable for your operating system, rename it at your convenience, then run it from shell or by double-clicking on it (Windows). You should see the following output:

    ---== Red 0.6.5 ==--
    Type HELP for starting information.

    >>

A simple Hello World would look like:

    >> print "Hello World!"
    Hello World!

If you are on the GUI console, a GUI Hello World (prompt omitted):

    view [text "Hello World!"]

A more sophisticated example that retrieves the last commits from this repo and displays their log messages in a scrollable list:

    view [
        text-list data collect [
            foreach event load https://api.github.com/repos/red/red/commits [
                keep event/commit/message
            ]
        ]
    ]

Note: check also the following improved version allowing you to click on a given commit log and open the commit page on github.

You can now head to see and try some showcasing scripts here and there. You can run those examples from the console directly using Github's "raw" link. E.g.:

    >> do https://raw.githubusercontent.com/red/code/master/Showcase/calculator.red

Note: If you are using the Wine emulator, it has some issues with the GUI-Console. Install the Consolas font to fix the problem.

Generating a standalone executable

The Red toolchain comes as a single executable file that you can download for the big-3 platforms (32-bit only for now). Rename the file to redc (or redc.exe under Windows).

1. Put the downloaded redc binary in the working folder.

2. In a code or text editor, write the following Hello World program:

    Red [
        Title: "Simple hello world script"
    ]
   
    print "Hello World!"
   

3. Save it under the name: hello.red

4. Generate a compiled executable from that program: (first run will pre-compile libRedRT library)

    $ redc -c hello.red
    $ ./hello
   

5. Want to generate a compiled executable from that program with no dependencies?

    $ redc -r hello.red
    $ ./hello
   

6. Want to cross-compile to another supported platform?

    $ redc -t Windows hello.red
    $ redc -t Darwin hello.red
    $ redc -t Linux-ARM hello.red
   

The full command-line syntax is:

redc [command] [options] [file]

[file] any Red or Red/System source file.

• The -c, -r and -u options are mutually exclusive.

[options]

-c, --compile                  : Generate an executable in the working
                                 folder, using libRedRT. (development mode)

-d, --debug, --debug-stabs     : Compile source file in debug mode. STABS
                                 is supported for Linux targets.

-dlib, --dynamic-lib           : Generate a shared library from the source
                                 file.

-e, --encap                    : Compile in encap mode, so code is interpreted
                                 at runtime. Avoids compiler issues. Required
                                 for some dynamic code.

-h, --help                     : Output this help text.

-o <file>, --output <file>     : Specify a non-default [path/][name] for
                                 the generated binary file.

-r, --release                  : Compile in release mode, linking everything
                                 together (default: development mode).

-s, --show-expanded            : Output result of Red source code expansion by
                                 the preprocessor.

-t <ID>, --target <ID>         : Cross-compile to a different platform
                                 target than the current one (see targets
                                 table below).

-u, --update-libRedRT          : Rebuild libRedRT and compile the input script
                                  (only for Red scripts with R/S code).

-v <level>, --verbose <level>  : Set compilation verbosity level, 1-3 for
                                 Red, 4-11 for Red/System.

-V, --version                  : Output Red's executable version in x.y.z
                                 format.

--config [...]                 : Provides compilation settings as a block
                                 of `name: value` pairs.

--no-compress                  : Omit Redbin format compression.

--no-runtime                   : Do not include runtime during Red/System
                                 source compilation.

--no-view                      : Do not include VIEW module in the CLI console
                                 and the libRedRT.

--red-only                     : Stop just after Red-level compilation.
                                 Use higher verbose level to see compiler
                                 output. (internal debugging purpose)

--show-func-map                : Output an address/name map of Red/System
                                 functions, for debugging purposes.

[command]

build libRed [stdcall]         : Builds libRed library and unpacks the
                                 libRed/ folder locally.

clear [<path>]                 : Delete all temporary files from current
                                 or target <path> folder.

Cross-compilation targets:

MSDOS        : Windows, x86, console (+ GUI) applications
Windows      : Windows, x86, GUI applications
WindowsXP    : Windows, x86, GUI applications, no touch API
Linux        : GNU/Linux, x86, console (+ GUI) applications
Linux-GTK    : GNU/Linux, x86, GUI only applications
Linux-musl   : GNU/Linux, x86, musl libc
Linux-ARM    : GNU/Linux, ARMv5, armel (soft-float)
RPi          : GNU/Linux, ARMv7, armhf (hard-float)
RPi-GTK      : GNU/Linux, ARMv7, armhf (hard-float), GUI only applications
Pico         : GNU/Linux, ARMv7, armhf (hard-float), uClibc
Darwin       : macOS Intel, console-only applications
macOS        : macOS Intel, applications bundles
Syllable     : Syllable OS, x86
FreeBSD      : FreeBSD, x86
NetBSD       : NetBSD, x86
Android      : Android, ARMv5
Android-x86  : Android, x86

Note: The toolchain executable (redc.exe) relies on Rebol encapper which does not support being run from a location specified in PATH environment variable and you get PROGRAM ERROR: Invalid encapsulated data error. If you are on Windows try using PowerShell instead of CMD. You can also provide the full path to the executable, put a copy of it in your working folder or wrap a shell script (see relevant tickets: #543 and #1547).

Running Red from the sources (for contributors)

The compiler and linker are currently written in Rebol. Please follow the instructions for installing the compiler toolchain in order to run it from sources:

1. Clone this git repository or download an archive (ZIP button above or from tagged packages).

2. Download a Rebol interpreter suitable for your OS: Windows, Linux (or Linux), Mac OS X, FreeBSD, OpenBSD, Solaris.

3. Extract the rebol binary, put it in the root folder, that's all!

4. Let's test it: run ./rebol, you'll see a >> prompt appear. Windows users need to double-click on the rebol.exe file to run it.

5. From the REBOL console type:

    >> do/args %red.r "%tests/hello.red"
   

The compilation process should finish with a ...output file size message. The resulting binary is in the working folder. Windows users need to open a DOS console and run hello.exe from there.

You can compile the Red console from source:

    >> do/args %red.r "-r %environment/console/CLI/console.red"

To compile the Windows GUI console from source:

    >> do/args %red.r "-r -t Windows %environment/console/GUI/gui-console.red"

Note: the -c argument is not necessary when launching the Red toolchain from sources, as the default action is to compile the input script (the toolchain in binary form default action is to run the input script through the interpreter). The -r argument is needed when compiling the Red console to make additional runtime functions available.

Note: The red git repository does not include a .gitignore file. If you run the automated tests, several files will be created that are not stored in the repository. Installing and renaming a copy of .git/.gitignore-sample file will ignore these generated files.

Contributing

If you want to contribute code to the Red project be sure to read the guidelines first.

It is usually a good idea to inform the Red team about what changes you are going to make in order to ensure that someone is not already working on the same thing. You can reach us through our chat room.

Satisfied with the results of your change and want to issue a pull request on Github?

Make sure the changes pass all the existing tests, add relevant tests to the test-suite, and please test on as many platforms as you can. You can run all the tests using (from Rebol console, at repository root):

    >> do %run-all-tests.r

Git integration with console built from sources

If you want git version included in your Red console built from sources, use this command:

call/show ""                                              ;-- patch call bug on Windows
save %build/git.r do %build/git-version.r                 ;-- lookup git version if available
do/args %red.r "-r %environment/console/CLI/console.red"  ;-- build Console
write %build/git.r "none^/"                               ;-- restore git repo status

Anti-virus false positive

Some anti-virus programs are a bit too sensitive and can wrongly report an alert on some binaries generated by Red (see here for the details). If that happens to you, please report it to your anti-virus vendor as a false positive.

License

Both Red and Red/System are published under BSD license, runtime is under BSL license. BSL is a bit more permissive license than BSD, more suitable for the runtime parts.

red's Issues

update quick-test docs to reflect new keywords

Specifically, --compile-this, --compile-and-run, --compile-and-run-this, --assert-msg?, and --clean (see the pull request in Issue #70, for details).

alias with self-referencing structs is broken

The line

str!: alias struct! [i [integer!] s [str!]]

does not compile

*** Compilation Error: invalid struct syntax: [str!]

A simple inversion of the lines

unless parse pos: pc/3 struct-syntax [throw-error ["invalid struct syntax:" mold pos]
repend aliased-types [to word! pc/-1 reduce [pc/2 pc/3]]

will solve the problem, I think (the parse needs the alias word to be defined!)

Fetching a structure member does not always work

The following program executes correctly:

  red/system []
  s: struct [a [integer!] b [c-string!]] 
  s/b: "hello"
  print s/b

But the following one does not, indicating that assignemtn of a fetched value is the problem, not storing or fetching as such.

  red/system []
  s: struct [a [integer!] b [c-string!]] 
  s/b: "hello"
  c: s/b
  print c

multiplication with byte! as second operand crashes compiler

One can multiply (divide, take modulo of) integers and bytes in any combination. The result has the type of the left operand. However when multiplying with a byte! as second operand, the power-of-two optimization plays havoc.

** Script Error: power-of-2? expected n argument of type: integer
** Where: emit-math-op

Compiler chokes on p: pointer ; without [integer!]

The error message is:

** Script Error: Cannot use path on set-word! value
** Where: emit-load-path
** Near: set-width/type type/2/1
idx: either path/2

problem with exit

f: func [return: [integer!]][if true [exit]]

Inspecting the compiler, the local variable ret is not always set on return from comp-exit. But then again, this may have nothing to do with it....

alias not preceded by set-word crashes compiler

comp-alias assumes that the lexical element preceding the word alias is a set-word and does a to-word on it. This crashes the compiler if the element in question is something different.

Try
1 alias integer!

function definition is allowed in the code block of a conditional statement

Try

either true [f: func [][print "hello"]]  [f: func [][print "goodbye"]] f

and you will see that the function re-definition is registered even if the second code block is NOT to be executed.

Some REBOL values allowed on input that are not usable

The current implementation of the compiler allows decimal! and struct! values (I mean REBOL struct! literals, presumably created with #[struct! [...][...]]) which are only trapped if they are used in an expression. They could be eliminated earlier in the process.

#include doesn't seem to accept absolute file paths

Code:

Red/System []
#include %/c/Red/red-system/tests/quick-test/quick-test.reds

Compiler output:

-= Red/System Compiler =-
Compiling /c/code/red-system/test.reds ...
Script: "Red/System IA32 code emitter" (none)
** User Error: Include File Access Error: /c/Red/red-system/tests/quick-test/quick-test.reds
** Near: make error! reform ["Include File Access Error:" file]

(non-value) exit from functions which return a value

Exit is allowed in functions which should produce a return value. If the error reported in the previous issue does not occur, the value resulting from the function call is probably arbitrary.

"attempt to change type of variable" not properly treated

I tried various combinations of subsequent assignments to values of different type. All are compiled with no error message except the following:

i: 0 
i: "A"
** Script Error: Cannot use path on none! value
** Where: emit-store

Issue #43 not really solved

The program str!: alias struct! [p [str!]] still gives an error.

Bug in set-width (?)

I was trying to write my own (primitive) version of the 'form function, and hit on the following bug, when compiling

red/system []
i: 3
s: "          "
s/1: as byte! ((i // 10) + 48)
print s

Result:

** Script Error: size-of? expected type argument of type: word
** Where: set-width
** Near: width: emitter/size-of? operand-type? operand

multi-line comment cannot be used inside until loop

code:

Red/System []
until [
  comment {my comment}
  1 = 1
]

compiler output:

-= Red/System Compiler =-
Compiling /c/code/red-system/test.reds ...
Script: "Red/System IA32 code emitter" (none)
*** Compilation Error: undefined symbol: comment
*** in: %/c/code/red-system/test.reds
*** at:  [
    comment "my comment" 1 = 1
]

alias definition allowed inside conditional statement

In analogy with the function definition case, one should perhaps disallow this too. In any case, the program

either true [str!: alias struct! [i [integer!]]][str!: alias struct! [b [byte!]]] s: struct str! s/i: 0

compiles alright, but changing s/i: 0 into s/b: #"A" gives a crash.

Infix operator in compound expression crashes compiler

The following code

myand: func [[infix] a [integer!] b [integer!]][a and b]
17 myand 13 + 1

crashes the compiler with error:

** Script Error: size-of? expected type argument of type: word
** Where: set-width
** Near: width: emitter/size-of? either type [operand]

logical and with byte! as second operand crashes compiler

The logical operations should take bytes as well as integers. However, a byte as second operand yields:

** Script Error: to-bin32 expected v argument of type: integer
** Where: emit-bitwise-op

error handling in red/system compiler

I have observed various styles of exception (error) handling in the compiler source:

1. a function throw-error, internal to the compiler context (%compiler.r) which is used also in the other source files (compiler/throw-error)
2. direct error! value creation, like make error! "..."
3. explicit test, like if error? set/any 'err try [...][print [... mold disarm err]]

This does not count the internal error checking done by REBOL2, e.g. type-compatibility of actual and formal function arguments. I suppose there is a rationale for each of the approaches. Still, I wonder if there is no scope for more uniformity, and/or a centralized error handling approach.

Subtle bug in byte comparison

I am trying to write a MOLD function for c-strings. This needs to encode bytes below 32 as ^A etc.(two characters). The following program fragment illustrates how I try to determine the length of the resulting string in order to reserve space for it. Unfortunately, it does not function as expected with bytes above 127. (printf is short for print form)

s: "á"
c: length? s
printf c ; gives 1 as expected
while [s/1 <> #"^(00)"][
    if s/1 < #" " [c: c + 1]
    s: s + 1
]
printf c ; gives 2 whereas the test on s/1 should fail

The program fragment

s: "á" either s/1 < #" " [print "NOK"][print "OK"]

gives a correct result. How come?

Dividing zero by maximum negative number crashes compiler

Code:
Red/System []
i: 0 / -2147483648

Result:

Note: following compiles okay

Red/System []
i: 0 / -2147483647

unexpected result of "complex" expression

The following simple program leads to an unexpected result:

Red/System []
a: "0"
a/1: a/1 + (2 * 2)
print a

I'd expect 4 as output, but @ is printed instead. For other expressions, the results vary (using 2 * 3 leads to 0 being printed, for example).

String comparison bug?

I have found that comparing a string variable with a string literal does not produce the expected result. I ran the following script:

Red/System []
str: "hello"
either str = "hello" [print "correct"] [print "incorrect"]
str2: "hello"
either str = str2 [print "correct"] [print "incorrect"]
str3: ""
either str3 = "" [print "correct"] [print "incorrect"]

and got the following results:

C:\Red\red-system\builds>test
incorrect
correct
correct

aliased type not accepted in struct, crashes compiler

According to the specification (4.5.5) one can use an alias name in a struct:

<variable>: struct <alias>
<variable> : a struct variable
<alias> : a previously declared alias name

I compiled the following program:

str!: struct! [i [integer!]]
s: struct str!

with the following result:

** Script Error: parse expected input argument of type: series
** Where: comp-struct
** Near: unless parse pos: pc/2 struct-syntax

Argument type checking in Red/System compiler functions

It occurred to me that, while most compiler functions are defined with type restrictions on their arguments, there are quite a few for which this is not the case. Example: set-last-type: func [spec], where one could have had func [spec [block!]], I suppose. Good for error detection and for documentation purposes, don't you agree?.

Multiplication by zero crashes the compiler

I've found that multiplying by zero crashes the compiler. Code:

Red/System []
i: 1 * 0

Compiler output:

do/args %rsc.r "%/c/code/red-system/test.reds"
Script: "Red/System compiler wrapper" (none)

-= Red/System Compiler =-
Compiling /c/code/red-system/test.reds ...
Script: "Red/System IA32 code emitter" (none)
** Math Error: Positive number required
** Where: power-of-2?
** Near: to integer! log-2 n

In function spec, argument identifier that is set-word! is not caught

I inadvertently typed result: [integer!] instead of return: [integer!] in a function spec. This was taken as an additional argument, leading to spurious execution errors. Incidentally, the error message was also not very helpful: instead of "missing argument" it said "datatype not allowed".

alias does not seem to work

I submitted the following program to the compiler

int!: alias integer!
s: struct [i [int!]]

with this result

*** Compilation Error: invalid struct syntax: [int!]
*** in: %tests/mytest.reds
*** at:  [struct [i [int!]]]

Same when using int! as type for a function argument

type casts not accepted for initialization

Both
i: as integer! null
and
p: as [pointer! [integer!]] 0

are not accepted by the compiler

length? could be made more efficient

The current definition of length? in common.reds could be replaced by:

#import [
 "msvcrt.dll" cdecl [
  length?: "strlen" [  ; Return string length.
   command [c-string!]
   return: [integer!]
 ]
]

at the cost of placing it in win32.r instead of common.reds. The equivalent libraries for the other OSs are libc.so.6 forGNU (Linux) and libc.dylib for Mac (courtesy of C-library binding by Kaj de Vos, http://red.esperconsultancy.nl/Red-C-library).

size? of non-simple value crashes compiler

The function size? should be applied to a literal or word/path. When applied to a struct, it produces a crash instead of a compilation error.

size? struct [i [integer!]]

Error:

** Script Error: Cannot use path on none! value
** Where: resolve-type
** Near: unless base-type? type/1 [
type: select aliased-types type/1

return as last statement in function crashes compiler

With the following input:

red/system []
f: func [return: [c-string!] /local s [c-string!]][s: " " return s]

the compiler crashes with (verbose = 4):

<<< return
<<< s
expr: s
>>>loading s
>>>emitting code: #{8B45}
>>>emitting code: #{FC}
*** expected logic! variable or conditional expression
at:  []

String variables are acting as immutable

Once a string is assigned to a variable it does not get changed by subsequent assignments. The following script (test.reds):

Red/System []
str: "original string"
print str
str: "second string"
print str

produced the following output:

C:\Red\red-system\builds>test
original string
original string

variable that is given a value by a cast is not recognized

The program

p: as [pointer! [integer!]] 0
p + 1

gives the error

*** Compilation Error: undefined symbol: p

dereferenced pointer not accepted as integer argument in function call

I was curious if the type of a dererenced pointer is indeed integer. Apparently there is still some bug...

f: func [i[integer!]][] p: pointer [integer!] f p/value

error:

-= Red/System Compiler =-
*** Compilation Error: argument type mismatch on calling: f
*** expected: [integer!], found: [pointer!]

Variable names are more restricted than documentation says

Section 3 of the specs suggests that the following signs are allowed in names: ! ' * + - . < = > ? _ ` \ ~ (computed by taking the complement of what is stated there to be forbidden). An exhaustive test revealed that \ (backslash) is also forbidden, and that ' < > cannot begin a name.

prin/print with non-string argument crashes compiler

A program which contains print 1 is compiled without protest, but when run produces a crash with Windows exception code 0xc0000005.

Cannot assign c-string value to struct member

The Todo-list says: "Structs members read & write access: implemented but untested." I compiled the following program:

red/system []
s: struct[a [integer!] b [c-string!]]
s/b: "hello"

This gave the following error message:

** Script Error: emit expected value argument of type: integer word tag
** Where: access-path
** Near: emit/head/store/struct path/1 value offset

residual problem in type-casting

Compiling the following program

f: func [i [integer!]][]
i: as integer! #"A"
f i

results in

*** Compilation Error: argument type mismatch on calling: f
*** expected: [integer!], found: [byte!]

Compiling a very similar program

f: func [i [integer!]][]
f as integer! #"A"

gives no error

when comparing bytes, sign is extended

Comparing a byte with an integer or another byte, the sign is apparently extended, leading to problems for charaters beyond ~ or #"^(7E)". Thus: #"á" < 0 is true. The second half of the ASCII table is forbidden for variable names, but should it also be forbidden in character strings and thus in bytes?

Compiler cannot cope with option link?: no

The wrapper %rsc.r calls system-dialect/compile with option link?: yes. If one changes this to no, a REBOL error ensues, namely the third element of the block returned by compile, length? job/buffer, cannot be computed (obviously, job/buffer remains none when there is no linking).

another curious type-casting matter

The lines
s: "A"
b: 255 and s/1
give a curious error:
** Script Error: Invalid argument: s/1
** Where: cast
** Near: value: to integer! value
whereas
c: #"A" b: 255 and c
compiles correctly

Using structure member as argument to function crashes Red/System compiler

Using a member of a structure as an argument to a function crashes the compiler. Example script:

Red/System []

tf: func [
    i [integer!]
][
    i
]

s: struct [
    j [integer!]
]

s/j: 1

tf s/j

produces the following;

-= Red/System Compiler =-
Compiling /c/code/red-system/test.reds ...
Script: "Red/System IA32 code emitter" (none)
** Script Error: emit-push expected value argument of type: integer word block string
** Where: emit-call
** Near: emit-push arg

exit and return are not checked for occurrence inside function

As a consequence, exit can be used anywhere, and return may crash the compiler if not within function, since the existence of the surrounding function is assumed for checking the return value type.

Documentation improvement

In the draft specification, sections 4.6.3 and 4.6.5, there are several examples each containing the statement

p: as [pointer [integer!]] 40000000h

If I understand correctly, this should be

p: as [pointer! [integer!]] 40000000h

Multiple castings not effectively forbidden, and non-existing types allowed.

The following program compiles OK:

p: as [pointer! [integer!]] as integer! null

What is worse,

p: as [pointer! [integer!]] as nonsense! null

compiles also!

type casting only accepted in assignment (not documented, and not properly checked)

When one tries to use a type casted value other than as right-hand side of an assignment, the compiler balks (in fact crashes with ** Script Error: call expected name argument of type: word). Try if 1 = as integer! true [print "OK"].

Chaining of function calls does not seem to work

I am continuing my work on a 'form function, and have a working version (could share with you if interested, although it is very primitive). But, ... the following calling sequence crashes the compiler in Windows with error code 0xc0000005:

print form length? form -21474

(should give 6, and it does if I store intermediate results in separate variables before calling the "next" function)

Red/System compiler has to be "re-booted" after it finds a compilation error

After compiling a Red/System source file which has compilation errors, the compiler won't compile correct source. The REBOL/View session has to be quit and restarted.

I ran the following test with two different source files: good.reds (print "hello") and bad.reds (print not-defined):

-= Red/System Compiler =-
Compiling tests/good.reds ...
Script: "Red/System IA32 code emitter" (none)

...compilation time:     10 ms
...linking time:         30 ms
...output file size:     2048 bytes
>> do/args %rsc.r "%tests/bad.reds"
Script: "Red/System compiler wrapper" (none)

-= Red/System Compiler =-
Compiling tests/bad.reds ...
Script: "Red/System IA32 code emitter" (none)
*** undefined symbol
at:  [not-defined]
>> do/args %rsc.r "%tests/good.reds"
Script: "Red/System compiler wrapper" (none)

-= Red/System Compiler =-
Compiling tests/good.reds ...
Script: "Red/System IA32 code emitter" (none)
** Script Error: Invalid path value: stdout
** Where: emit-variable
** Near: emit-reloc-addr emitter/symbols/:name
>>

implicit type casting allowed for math-ops between pointer types and bytes

In the title, pointer types stands for [c-string! pointer! struct!]. The same implicit type conversion is not allowed for assignment. This extension may be deliberate, but is it really? Bytes are too short to be pointers.