World: r3wp

Looks great John.

Gregg wrote in group #Red: "World has similar goals I believe."


Yes. To clarify: There is World and there is World/Cortex. World 
is written in C and the Cortex extension is written in World. It's 
a design goal to have as little as possible in the C part, but because 
it's also a goal to have good performance, especially with math stuff, 
some functions are native (written in C), which could have been mezzanines 
(written in World), like ABS, COS, SIN, TAN (all small functions 
in C).


But large functions like PARSE and SORT and many other functions 
are part of the Cortex extension, so they're written in World and 
is therefore open source.


With the good support for dynamic loaded libraries, good performace 
with heavier functions can be achieved that way.


And then there is the REBOL extension (in the World file %rebol.w), 
which is there to hold further extensions and definitions needed 
to run REBOL scripts. Those are not in the Cortex extension, because 
I disagree with some of the REBOL design decisions, and because I 
would like the Cortex extension not to be too large.


For me, World and Cortex has the higher priority, the REBOL extension 
the lower priority, meaning I use more time on finishing World/Cortex 
for now.

Great info John. THanks.

Geomol - could you please explain, how wrapping libraries in World 
are done? Call me dumb, but I can't understand it from a website. 
OK, found more in PDF docs. I just wonder, if I always should use 
typecheck? Eg. I wanted following function to return 0 or 1. I tried 
with variou int types on the C side, and integer! datatype on the 
World side. I was receiving very large integer numbers as a result, 
untill I put [typecheck] in there. Maybe I just had incorrect argument 
type on the C side selected?

led: load/library %ledctrl.dll

led-is-power?: make routine! [
   [typecheck]
   led "LSN_IsPower" []
   uint integer!
]

World is 64 bit. If you don't specify typecheck, it assumes the return 
value to be a 64-bit integer, e.g. sint64 or uint64 in C and integer! 
in World. If the return value of the C library routine isn't a 64 
bit integer, you need to specify typecheck to get it converted from 
8, 16 or 32 bit to 64 bit. If the return value of the C library routine 
is 64 bit, typecheck isn't necessary, but can still be used, and 
it will slow the routine call a bit.

I say C, but the library can be made with any language, I guess. 
It's just, that the C types (actually typedefs) are used in the explanation.

Maybe typecheck should be default, even if it hits performance, when 
it isn't needed, and then some other word should be used to remove 
typechecking (and conversion)? Argh! I don't like to change that. 
:)

Well, a trade-off :-) It is about to get the most expected result 
preferably, vs your mentioned speed :-)

What about a compiler option to turn on and off the typecheck? More 
complicated, but we would have a chance to run in default (typecheck) 
and then test it without typecheck by changing just one option.

After I wrote the above, I considered it some more. Right now, most 
people will probably run into this problem, because most libraries 
return 32 bit values. But in the future, and with what World is very 
much designed for, namely science, 64 bit values will be used. So 
I'm not gonna change it.


Problem with compiler option is, that we then have two versions of 
World, and programs made for one won't run on the other.


Maybe better to make a World wrapper function with it's own routine 
definition dialect!?

Like ROUTINE is a helper function calling MAKE ROUTINE!, a ROUTINE32 
(or something) can be made to have typecheck as default.

with *its* own ...

But we should set the option in the (on top of) source code, not 
in runtime, so it should not be a problem having 2 versions of World. 
We can say "compile this source with "typecheck" options". No?

ah, I'll consider that.

In the boot time of World compiler some functions changes according 
to some options. As in "Option Compare", "Option Explicit" options 
in VB6.

Continuing from #Not REBOL. A MORE? function could look like:

more?: make function! [[
	"True if a series isn't empty."
	series [series! none!]
][
	if none! = type? series [
		return false
	]
	0 < length? series
]]

Could also be made easier to read maybe, but slower:

more?: make function! [[
	"True if a series isn't empty."
	series [series! none!]
][
	not any [none? series tail? series]
]]

And to make is less confusing, the function description should probably 
read "True if a series isn't at its tail."

Working on the next release of World, I implemented coercion for 
words and datatypes, so things like block! = 'block! returns true. 
This lead to a much simpler implementation of SWITCH, which is a 
mezzanine in World, so it looks like I'm on the right track.

Another point talking against open sourcing at this time. World is 
not completely set in stone yet, I admit that. When I make design 
changes like this coercion between datatypes and words, it affect 
all other code, which can fast become a mess, if you have 10 people 
working on it. When it's completely set in stone, it's another situation.

Update!


I'm implementing support for cyclic series in World these days. My 
initial research about freeing memory taken by cyclic series made 
me realize, that it'll hit performance, if every block and paren 
freed is being tested for cyclic references. So I'll implement a 
FREE mezzanine written in World, that can free such structures. This 
lead me to molding such structures, which is only partly implemented 
in current version of World and copying such structures. Those functions 
will be mezzanines too, as it's much easier to write the code in 
World than in C. So some C code will be removed in next release, 
but we'll have some more World code instead.

Btw. COPY is by defauit deep in World (contrary to REBOL), and World 
will support deep copying of cyclic blocks, which gives a stack overflow 
error in REBOL.

no cyclic error in R3 IIRC (it was fixed in some alpha).

In one of 114 alphas :-)

Maxim, the fix was requested for R3 but not yet implemented, or planned.

hum... strange I feel like it was fixed, since at some point, R3 
coudn't make objects which I required, then, when Carl did the whole 
copy/make makeover, I was able to start using R3 because of deep 
copying issues being resolved ... maybe it was not completely fixed.

I don't think that was about cyclic structures

yes.. definitely but I think Carl may have only fixed it for cyclic 
Objects references.