World: r4wp

Red runtime library

Sorry for the dumb questions, I've been too busy to participate yet 
:(

Semantics will be very close, probably 99% close, as I've moved from 
a statically typed system to an hybrid static/dynamic typing system.

So, no lexical binding? Or do you plan to infer lexical binding where 
possible, and use direct where not?

So, if all goes well, you'll have the full REBOL model + optimizations. 
There are many ways to optimize and on many different abstraction 
levels. Yet, some atomic operations will remain "unoptimized", like 
series atomic manipulations (maybe we'll figure out a way to optimize 
them too in the future).

Lexical binding will be added when we'll add contexts (in a few weeks), 
along with dynamic binding (yes, you'll be able to have fun with 
BIND again ;-)).

In a couple of days, I'll release the first Red alpha with a blog 
entry to describe it, you'll be able to get a better picture of what's 
in Red already and where it's heading.

So, my module system will end up being of more use to you. I'll be 
sure to write up that TRANSCODE/part option request for R3 in CureCode, 
for your reference.

I ran into the need for that with multi-scripts.

Well, maybe. :-) I must admit I haven't yet dived into R3 module 
system to see if it fits well our needs.

our needs
: they are not yet clearly defined, btw.

It isn't specifically for R3. Most of the design decisions were based 
around the constraints of the direct binding model, and of making 
it as simple as possible for people who are not used to modular programming 
to use. Beyond that, we just made it as powerful as possible without 
killing the usability.

Being simple

 is probably the most important feature I would require from a module 
 system.

There are still some parts that I could use a little help with though, 
like resolving import cycles. And there are some bugs and/or weaknesses 
in the native code that I've had to work around in my patches collection.

The "being simple" part was mostly driven by Carl. I tried to make 
it simple, but it took some doing to make it even more simple for 
Carl. There's a lot of subtle code in there to make it simple enough 
for Carl to want to use it.

Resolving import cycles

: we've solved that in Red/System compiler by having a simple "included 
files" list and it stops inclusion if already done once. But we do 
that at compile-time, so it's easy.

I thought that something similar would work for R3, but haven't done 
it yet. R3 releases kind-of stopped before I got the chance.

A module system is where you would find a lot of places where the 
internals would be different, due to the compilation thing, but the 
external behavior could appear to be the same. There are a lot of 
nice tricks in R3's module system, and I've gone through a lot of 
trouble to make it possible to have the module system be handled 
by a preprocessor that doesn't have to execute any of the code in 
the modukle bodies to resolve dependencies. It was designed with 
preprocessors like prebol or Ladislav's include in mind. And all 
of that is in the specifications of how modules are declared, not 
in the actual mechanism that implements it, so the concepts would 
be portable to Red.

There's no reason that Red couldn't also implement compressed scripts, 
checksums, multi-scripts and embedded scripts the same way too. All 
of those apply to all scripts, not just modules, so they could work 
the same way for runtime-compiled Red scripts as well.

Certainly, but AOT compilation would be a big plus. Also, in Red 
we need to modularize the compilation process itself, so  we can 
do incremental AOT compilation on multi-files projects instead of 
having to rebuild everything (include runtime libraries) each time. 
We need to, somehow, match those compilation units with the higher-level 
module system (it's not the only option, but probably the most simple).

Multi-scripts would be mostly a packaging method. It could even help 
AOT compiled scripts at the script distribution phase. I'm thinking 
of install-time-compiled scripts, for instance. It would also help 
with mixed-Rebol-Red projects like what I described above for R3 
extensions. Also, it could help for data files in some cases, or 
metadata embedded in other files.

Well, the R3 module system is designed to be statically resolvable, 
so the same method would work for resolving Red modules in a project.

That is why Needs and Exports are headers rather than function calls, 
and export and hidden are module-code-block keywords instead of functions. 
You can determine the whole dependency chain by loading the script, 
examining the header, and searching the top block of the source for 
the keywords.

The same goes for extensions - their embedded module wrapper is treated 
like any other module. You could AOT compile R3 extension wrappers 
that dynamically load the extension's native code at runtime.

Here are block-embedded multi-scripts:
[rebol []
print "hello world"]
[red []
print "hello world"]

Here are length-specified multi-scripts (which can be faster at times):
rebol [length: 19]
print "hello world"
red [length: 19]
print "hello world"

Note that if you specify the length, it applies to the length of 
the script after the header and an optional newline after it (cr, 
crlf or lf). Same goes for the checksum. Both apply to binary data, 
meaning the source in UTF-8 encoding and with newlines in the style 
that they are specified in the file.

With compressed scripts, you can either have raw compressed data, 
or binary! syntax compressed data, after the header and an optional 
trailing newline. If you have raw binary data and a length header 
then it is only decompressed until the end of the length (with DECOMPRESS/part). 
The option of binary! syntax is useful for block-embedded scripts 
or scripts posted in a text environment, and it doesn't really combine 
well with the length header so that is ignored in this case; one 
of them had to take precedence (until I get TRANSCODE/part) so I 
picked compression. It is more likely that the length header and 
raw compressed data would be combined, anyways, For compressed scripts, 
the checksum applies to the decompressed binary data.

install-time-compiled scripts
 We'll support that option too.


Statically resolvable module system: that's a very useful feature 
to have, not only for compilation, but for auto-documentation generation 
too.

The same method that is used for compressed scripts could be used 
for encrypted scripts too, or for precompiled modules that you are 
packaging together. The same method used for checksums could be used 
for cryptographic signatures as well.

This also lets you store scripts or modules in databases too.

You should take upcoming red|rebin format also into account. That 
might be a preferable method sometimes rather than compressed scripts. 
Red will pre-compile most of the scripts content, but we might keep 
some "code" blocks in source form for reflection (when used by the 
script and inferred by the compiler).

I wanted to publish my redbin specs earlier, but stopped when I read 
that R3 might use a copyleft license.

The community is leaning more towards Apache now, so as long as you 
don't patent redbin (or grant use of the patent) it would be usable.

An asymetric permissive licensing model between Red and R3 might 
prevent me from publishing info about what we'll do next, to prevent 
the features from being implemented first with a copyleft license 
attached. It would just be unfair to Red, so I would have to be cautious 
about that.

Don't underestimate the value of treating the header and the rest 
of the script differently. It lets you put a lot of static information 
in the header without even looking in the sctipt data at all.

Right, the header is a great source of metadata.

Yes, most of us are wary of copyleft licenses for that reason.

If Carl is really honest about cooperation, he should just pick one 
of the permissive licenses and be done with it.

Given that he's getting advice from Rosen, something like Apache 
seems likely. He has already shown a certain scepticism for the need 
for copyleft in this case. One can hope, at least.

I threw in a hint for a new license, the URL or Unified REBOL License, 
for the best of both worlds.

Given the momentum on Red and huge potential, the similarities to 
the original. To me the wait on the license almost cannot take long 
enough. But waiting is boring and the longer it takes that is not 
in the interest of any party.

Sorry that should have landed in Licenses.

Doc-strings are now allowed in Red/System function spec:

https://github.com/dockimbel/Red/commit/b7f46eafe75b43f43d7cb282d4415e89c2858a5e


So, who's going to write a short and nice REBOL script now to extract 
them (extracting also the context where they are defined)? :-) Ideally, 
those info should be collected into a simple nested block structure 
that can be easily processed for generating formatted text output, 
HTML, PDF (using pdf-maker lib), ... (take make-doc.r script as example 
of parser/emitter separation, and plugable emitters).

Another 30 euro for the great works..

Thanks Endo!

You're welcome! I use Cheyenne too in my business and I didn't donate 
for it before, so I feel guilty a bit, and do it for Red :)

Merge of 0.3.0 branch into master done. Do not use v0.3.0 branch 
anymore for new commits.

I have just succesfully run demo.exe and got nice Ascii Red, created 
from Red letters :-)

The executable file size is 59904 Bytes, quite big :-)