World: r4wp

The Red interpreter can now actually load and run REBOL scripts, 
as long as they're compatible and they don't have a Unix shebang 
line

I could check for the shebang line in the console

Now that REDUCE is implemented, I suppose it's time for PRINT to 
reduce its argument?

Fibonacci is a good such test, isn't it?
 It is a very good test for nested calls. :-)

PRINT: yes we could enhance it, but it would need to be promoted 
as a "keyword" in the compiler (not a big deal though).

I still have work on MOLD tomorrow, I'll try to do PRINT too.

There are also some refinements for some natives that are implemented 
in the compiler and not in the interpreter (/any for SET and GET 
from top of my head, but there are probably more). I need to do a 
review to collect them and implement them before the release (probably 
on Sunday).

Are you sure PRINT can't just be a function?

Yes, it is a function, but the reduction (on literal blocks only) 
could be handled by the compiler if it's also declared as a keyword 
(in the compiler).

Function => native

So `print [1 + 2]` could be compiled efficiently by the compiler 
(calling the native with a reduced block), while `print a` will directly 
call the native version.

Would you have to do that with all functions that reduce?

Currently, REDUCE and COMPOSE are handled like that by the compiler.

They have a native common part anyway, as some parts cannot be statically 
compiled.

But REFORM etcetera?

These less used functions could be implemented as mezz only.

I'm not sure which are more performance critical

It is not mandatory to make the compiler handle it, it will just 
produce faster code, as the expressions will be statically compiled 
instead of been interpreted.

It would be good to have some benchmarks on these to see the gains 
the compiler brings (it will be vary a lot I guess).

-be

I don't see COMPOSE in the intrinsics

Shouldn't DO be an intrinsic, so it can compile literal blocks?

Right, I've removed COMPOSE as an intrinsic, the implementation was 
too complicated and wasn't better than the purely native version.

DO: it was supposed to be handled by the compiler for literal blocks, 
but as it is the main way to invoke the interpreter, I wanted it 
to be consistent whatever argument was passed.

Also, later, I realized that if I make DO an intrinsic, expressions 
in functions like: `do [foo: :bar]` (where `bar` is a function) would 
be more complicated to write for the user, as the literal block would 
be compiled, loosing the advantage of interpreter here. So it would 
have required user to write instead: `code: [foo: :bar] do code`.

Hm, intricate

So REDUCE is the most performant of all?

Andreas' R3 build is a bit slower even than mine, so nothing wrong 
with mine it seems. Apparently R3 is 10% slower than R2 on Fibonacci 
40

(On my machine, current constellation of the stars, etcetera, etcetera)

:-))

Right, REDUCE on a literal block should be the fastest way to evaluate 
code dynamically, for now.

Do you know of any other language that intertwines an interpreter 
and a compiler so intimately?

No, not the way Red does it (static AOT compiler + interpreter), 
but as there are thousands of languages out there, I guess that there 
are probably others that use the same technique.


Thinking about that, there's a more classical approach used by some 
JIT compilers like LuaJIT, that by default runs under an interpreter, 
gather runtime stats, then starts replacing some nested loops with 
JIT-compiled code (principle of a tracing JIT). So, such architecture 
implies an interwined interpreter and JIT-compiler.

Maybe some Lisps are using the same approach than Red, but I'm not 
aware of any.

Almost time to wake up...but I haven't gone to sleep yet. :-) Good 
night!

Same here. Night

It's hard to debug in the interpreter because it doesn't warn for 
undefined values. Would that be much work to implement?

On the other hand, unknown paths now exit the interpreter with an 
error. That's what they should do, but the error currently can't 
be trapped, so it makes tools such as GTK-IDE unworkable

Could both these situations issue a warning and not an error for 
now?

That should be doable.

Another 40 eu goes to Doc, for the great progress!

Received it, thanks a lot Endo!

Added preliminary file! support (doesn't work from compiler yet, 
only from interpreter).

red>> a: %dev
== %dev
red>> type? a
== file!
red>> length? a
== 3
red>> append a %/red/hello.red
== %dev/red/hello.red
red>> length? a
== 17
red>> find a slash
== %/red/hello.red
red>> index? find a slash
== 4
red>> form a
== "dev/red/hello.red"
red>> mold a
== "%dev/red/hello.red"
red>> a/1
== #"d"
red>> last a
== #"d"
red>> a/5: #"R"
== #"R"
red>> a
== %dev/Red/hello.red

I will add compiler support later today.

Very cool Doc!

I'm counting 27 datatypes implemented so far in Red. The next on 
the list will be: typeset!, errror!, object!, port!, binary!. Although, 
I'm not sure in which precise order they will be added (especially 
for error! and object!, not sure which one I'll do first).


For other datatypes, like float!, date! and time!, which are not 
a requirement for building Red core itself, I would like them to 
be contributed if possible. I could provide a sample empty datatype 
file and instructions on how to use Red's current internal API to 
anyone willing to work on them.

image! :-)

vector!

Vector! is a bit tricky and I might use it for parallel processing, 
so I will probably implement it myself.