World: r3wp

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 []

I wish you luck with World. It may be a bit difficult for me to use 
it though, because of the ASCII strings. Any language that isn't 
built from scratch with Unicode strings, instead having them retrofitted 
later when the inevitible need to support users outside the the English-speaking 
world, will have a great deal of problems. Python 3 is just the latest 
example of the problems with not having a well-thought-through Unicode 
string model. One of the best parts of R3 is how well we handled 
the Unicode transition.

I even have difficulty using R2 now because of how it can't really 
support nvarchar columns accessed through ODBC, a daily problem for 
me.

Any language that can do aliasing between the string and binary types, 
rather than requiring conversion, won't work.

Fortunately, it's not too late to fix this in World :)

My view is, implementing unicode everywhere will add to unnecesssary 
complexity. Each such level of complexity is a sure step to downfall. 
My first rule of development is simplicity, then performance, then 
low footprint, then maybe features.


Words in World can hold 7-bit ASCII. Chars and strings can hold 8-bit 
characters. That's the level of simplicity, I aim at.


I will have to deal with unicode, of course, and I'll do that, when 
World is a bit more mature. There could be a unicode! datatype.

A word about license, since that has been brought up in different 
groups. The current license for World is simple:


Alpha release. For testing only. Use at your own risk. Do not distribute.


There is a LICENSE function to show that. World is currently an alpha 
version for testing. When World moves to beta stage, I have to figure 
out a proper license. (I think, that's in the Q&A too.)

New release at https://github.com/Geomol/World

- Added /reset to COMPILE
- Implemented error system. Error system include:
	system/standard/error
	system/standard/errors
	system/state/last-error
	Better error reporting
- Added sys-utils/print-last-error

Uploaded new version with quick fix, in case someone downloaded latest 
release.

New blog "One week of open alpha" at http://world-lang.org

There is a lot of interest from people from France in REBOL-like 
languages, it seems. The month stats for world-lang.org shows most 
visitor from France, closely followed by Denmark and United States. 
Then Germany, Switzerland, UK, Czech Rep., Japan, Canada and Malaysia.


I should say, that I informed my SAS friend from France about this, 
so he could have spread the word too.