World: r3wp

I am not religius to my I will light a Candle in any case a GOD exists 
and could help you :-)

too

:) Thanks!

Well, good luck but as in the tech news .. HP paid $1.2bn for WebOS 
and are now open sourcing it

I just thought of another way to help. Make a list of REBOL functions 
missing. There are many missing from %rebol.w

And there already is a wiki started with differences from REBOL at:
https://github.com/Geomol/World/wiki/Differences-from-REBOL

I don't have time to write it. But everybody can write in that wiki.

Now, go try World out. And remember to have fun!

You're welcome to tell HP or anybody else about World.

I second Giuseppe.

I will not invest any time or money in a new closed source project.
Not anymore.

Geomol, do you really think you can follow the same model than Carl 
with better results ?

You should aknowledge the fact than nobody win money just because 
they designed or a created a new programming language.
I was possible back in 90's but not anymore.

I am sure I won't convice you about open sourcing it showing only 
advantages but I am curious: which are the disvantages you see in 
open sourcing the Language ?

I have my hands full now, and I make really good progress. When we're 
around version 1 (or if I don't make more progress), it would make 
much more sense to think about open source. And as I've said, it 
may also make really good sense to open source parts along the way. 
I have considered library.c and library.h, which holds the C code 
for library! and routine!. That almost makes sense now. When I've 
implemented error! correctly (working on it), it really makes sense. 
You have only been able to run World for 5 days. Patience! :)

Disadvantages: me loosing focus and loosing time, when having to 
answer all kinds of questions and approve new developments. The horror 
of World being fragmented to 100 versions, where none of them are 
compatible. You wouldn't like that! I make sure, that doesn't happen.


You need surplus of time and resources to open source things like 
this, if you wanna be sure, it doesn't run off rails. Look at how 
many ways, you can do any single thing in Linux. It's way too fragmented 
in most areas.

Of course, there are now six in-development ways to write a program 
in a REBOL like language, half of which are closed source

So haft are open. Do you have a general view, how things are going 
with the different languages?

Yes, efforts are quite fragmented over all these projects. Syllable 
is even still using a seventh language because I can't keep up

It probably doesn't make sense to join forces of all these languages, 
because they're so different in goal/implementation/design.

And it may make sense to share code in some areas.

It's actually a lot like Linux. Every distro has something you need, 
but none of them has everything you need. If I want to build the 
Russian Syllable website, I can only use R3. If I need system integration 
and speed, I can only use Red. If I need to write web apps, only 
Topaz targets that. If I need open source, I can only use half of 
them. If I need dynamic binding, I can only use the interpreters. 
If I need infix operators, I can't use Boron, although I could use 
its predecessor. Etcetera ad nauseum

I feel, trying to do everything has high possibility of failure. 
But being able to integrate with everything could be the way to be 
able to do everything.

I feel not trying to do everything equals failure from the start. 
A language is supposed to cover everything

This is the main reason REBOL has slided for a decade

But doesn't "trying to do everything" mean, it becomes bloated and 
complex?

Jack of all trades, master of none.

REBOL started out as a Swiss army knife, and was it bloated and complex?

But still, I strongly believe in the value of "general purpose language", 
though I wouldn't go as far as saying that one is supposed to cover 
"everything".

well, you didn't have direct support for things like Soap in REBOL, 
which I think is a good thing. Being able to integrate with stuff, 
that can do Soap is ok.

Red solves it by covering everything with two

REBOL was always meant to straddle everything with domain specific 
dialects

Andreas, I've thought some more about the need for a compile state 
reset. Have you?

Not much, no. But that also means I haven't yet changed my mind and 
still believe we need one :)

("Domain specific dialect" is just another label for "yet another 
purpose-built language".)

:) I see it as:


I have compiled function, I would like to change -> I make changes 
-> I want the new version to run


With compile reset, that can be cone at any point between first run 
and second. Doing it with COMPILE, it needs to be done right before 
2nd run. But isn't that good enough? Or can we come up with situations, 
where it isn't?

cone = done

Well, just remember the example we had.

This:

c: copy []
f: func [x] [x]
append c [f 10 20]
;; recompiling c here, do c would == 20
f: func [x y] [x * y]
;; recompiling c here, do c would == 200

I have a compiled block which I need to change. I make changes. In 
some cases, compilation state is automatically reset (INSERT), in 
other cases it is not.

If I, as a writer of some code-modifying helper function want to 
also provide the behaviour of INSERT, I can't.

Doing it with compile, the recompilation is forced to happen right 
after the modification.

If we had a compile reset, we could postpone the recompilation until 
the next evaluation.

Right, good explanation. Would a compile/reset be an idea? It doesn't 
compile, just reset.

Yeah, sounds perfect.

as a refinement, I mean

ok, consider it done

Nice, but no hurry :)

It's maybe 5 lines of C code. :)

Sure :)

Ah, I would like to do compile/reset/at too, so it's maybe a little.

About instructions being 256 bit, half can be used to hold constants 
of the types:

- complex! : 2 double
- range! : 2 64-bit int (also pair! in the future)
- tuple! : 14 bytes + length (could be 15 bytes)
- date! : 128-bit in all


The rest is used for opcode, type of constant and a register offset. 
I put a 32-bit filler in, when going from 32- to 64-bit to reach 
a 64-bit boundary. So it should be possible to go down to 192-bit 
instructions without loosing functionality. To reach 128-bit instructions, 
the above constants needs to be spread over two instructions, which 
will hit performance. But it's important to notice, there is room 
for improvements here.


It hasn't been important for me to uptimize in this area yet, so 
that's why it is like this for now, but that time will come.

On the other hand, on a 64-bit system with 64-bit pointers, compiler 
optimisation of code such as:

	0 GET_TVALUE	0		10031dff0
	0 GET_TVALUE	1		100150fa0
	0 ADD			0		0		1
	0 SET_TVALUE	10016f6f0	0


will require 192 bit just for the 3 pointers, which will mean 256-bit 
instructions (with opcode), if the code can be optimized into 1 instruction. 
Optimizing four 128 bit inst into one 256 bit inst will halve the 
memory required. I haven't dug enough into optimisation in World 
to say, if it's possible.

The above VM asm is produced by code such as:
	a: b + c

World should accept REBOL [] as header to run R2, R3 scripts through 
it without editing these.


World can already run scripts without header, so it's possible to 
run REBOL scripts without editing them by first defining REBOL as:

	REBOL: none

or something similar.

You can write this and it will work in R2 and R3, because the stuff 
before the header will be ignored:

world []
rebol: none
rebol []