Interesting to see...though of course an indictment of Red/System if it's really not good enough to use after all these years.
(Had the LOAD-able IL been some kind of compatible subset of LLVM--as I had suggested--then things would presumably be different. Because you'd have the choice to install Clang and run it through that.)
Because you're transpiling to C, this actually could be used as an alternative implementation language for user natives:
https://rebol.metaeducation.com/t/no-preprocessing-no-ffi-just-awesome-rebfunction/2224
; Block condition if [a > b] [ print "a is greater" ]
As you're using a Rebol parser, any real reason to make that a BLOCK! and not a GROUP! ("paren!"... I forget anyone actually still calls it that...)
void! — No Return Value
The
void!type represents "no return value". Functions without areturn:spec return void:log: func [msg [string!]] [ print msg ] ; log returns void — cannot be assigned log "hello"
Since you are introducing the term VOID!, I will mention that what you call VOID! (the result of a function with "no interesting result") I would call "TRASH!"... because to me VOID! is a purposely "vanishing" value.
>> 1 + 2 print "Hi" ; PRINT gives TRASH!, will show nothing in console
>> 1 + 2 () ; empty GROUP! makes a VOID!
== 3
>> 1 + 2 comment "hi" ; comment makes a VOID!
== 3
TRASH! is neither truthy nor falsey--it gives errors in things like ANY and ALL. But you can use ELIDE to evaluate an expression and return VOID!, which is ignored by them.
>> all [1 + 2 print "problem" 3 + 4]
problem
** Error...
>> all [1 + 2 elide print "okay" 3 + 4]
okay
== 7
It's my feeling that this "opting out" is the best application of the term VOID! (the word connotes with "vanishing" or "not even there"). I think it's nice for instance to have things like APPEND be a no-op if passed a VOID!, but error when passed a TRASH!
>> append [a b c] ()
== [a b c]
>> append [a b c] print "then this is an error"
then this is an error
** Error ...