World: r4wp

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.

Image! could be contributed too (would require loader and savers 
do be also added).

Image! should be built as an add-on module, that you choose to import 
in your app.

IIRC, vector! and range! were not even precisely defined for R3, 
so those two might use some discussions between our two projects 
...

I don't want to import anything :-)

Pekr: think SDK! :-)

But don't worry, you'll have your fat single all-in-one binary too. 
;-)

well, OK - so I might built full-contained Red executable with all 
stuff which I need?

The thing is, if I will have to use import, or not - how that module/component 
system will work. Btw - what were technically R2 components? We could 
see them in system structure ....

Yes, you'll be able to just build your fat binary/interpreter yourself 
including whatever module you want.

ok I am fine with that then ....

That is precisely what Kaj has done with his console-pro binary, 
including several of his own bindings.

Don't ask me details on the module/component yet, I haven't decided 
on the best approach. I just know that I want it to be as simple 
as possible.

Doc, will we have anything like R3 environment stuff - e.g. delayed 
loading/bootstraping, some debug stuff, being able to trace memory, 
time of running app, etc?

You'll have much more sophisticate debugging tools in the Red IDE. 
;-)

I agree - R3 modules have to prove themselves first - we live way 
too long without them, most users are used to contexts ....

Well - IDE is IDE, I mean - the runtime stuff. Simply put (and most 
probably worrying unnecessarily and sounding like a broken machine), 
let's make R3/Red another Amiga like OS :)

You'll have some of the debugging features accessible from the console.

Having an outline for implementing types will be great. I have looked 
at the current code, and they are laid out very clearly, but notes 
on how the slots work, so implementers don't assume something that's 
incorrect would help. And also how best to leverage work in similar 
types.

Doc, will you implement this, too?

red>> b: %x
== %x
red>> b/y
== none

No flooding or trying to prove anyone wrong. I'm happy to see improvements 
and progress in Red's development. There is no Red-vs-R3, we're all 
in this together.

There are some things in R3, particularly some of the things that 
the module system can do, that probably won't make sense to do in 
Red because it's compiled. Delay-loading modules won't be as important 
for Red because most of the overhead of creating a module can be 
done ahead of time when it's compiled. It would make sense to support 
the delaying feature because you might want to have a module's side 
effects happen at a particular time, but the delay can happen a lot 
later in the process than it would in R3. Red might benefit from 
the options specification method and some other aspects of its surface 
API and behavioral model, but the implementation would be completely 
different. The restrictions we made to make the module system statically 
resolvable (in R3's case by a preprocessor like prebol or Ladislav's 
include) would be a lot more important for Red than they have been 
so far for R3, because compilation makes static resolution more important.

In many ways, R3's module system design is even more beneficial for 
a language like Red than it is for R3 itself. Actually, that was 
one of the things I was taking into account when we were thinking 
it through. Back before Red was announced I was thinking about putting 
a JIT compiler into R3, and R3's extensions are similar in some ways 
to what modules would be in a Red-like language. So R3's module system 
was basically designed with Red in mind.

In order for R3 to get the full benefit of its module system, Ladislav's 
include and Saphiron's encapper would have to be enhanced to use 
and process them. Red can get the benefit from day one just because 
it's compiled.