World: r3wp

llvm-gcc support has been dropped in the most recent LLVM release 
(3.0), so definitely use clang whenever you can.

I don't think that LLVM/Clang claims to be much better in runtime 
performance over GCC, at the moment.

The resulting binaries are, at the moment, generally comparable to 
GCC-generated ones. GCC is better in some areas, LLVM/Clang in others.

However, _build_ times with Clang should be superioer, but that won't 
matter much for World, I think. Error messages from Clang should 
also be much better. Esp. for C++, but also for C.

ok, I think, most believe, LLVM/Clang is about performance.

So it's more about portability and maybe better error messages?

For typical end-users, clang is about fast compilation and good error 
diagnostics (at the moment).

ok,thanks

Clang also explicitly aims at GCC compatibility, so switchting to 
it from GCC is generally rather easy.

I'm confused Geomol, you're not aiming LLVM to perform jit within 
#world  but to compile the VM of #world ?

Yes.

but...

what is the interest, I mean when compared with standard C compilation.

That is just standard C compilation :)

uh !

LLVM/Clang is actually the default toolchain in Xcode4, for example 
:)

IIUC, John tried LLVM to see if the resulting binaries would performan 
better than GCC-compiled ones.

ah ok, but is there any other motivation behind the scene like to 
be able to compile code on the fly instead of generationg bytecodes 
for the VM ?

I mean LLVM can support JIT or is that another toolchain ?

LLVM can also be used as a set of compilation libraries, yes. And 
you can implement a JIT that way, yes.

But they also provide a set of ready-built binaries which work as 
a nice AOT compiler for C/C++/ObjC. I.e. just like GCC or MSVC or 
ICC or ...

John, you may want to try -Os. Optimising for size often leads to 
best speed, too, on modern architectures due to caching efficiency. 
OS X is also compiled that way

Thanks, Kaj. I will try that.
Steeve, it was just to try another compiler.

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

For now, it's possible to run REBOL scripts with this function:
do-rebol: func [file][do skip load file 2]

R3 scripts only require the REBOL header if they're modules/extensions.

Or when you want to put documentation before the header, or embed 
the script in a block in another type of file.

Ok, worth to consider.

That's why you don't need to write the REBOL header at the command 
line, even though those commands are just passed to DO like any other 
script :)

Kinda the same in World with the command line.

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

- Gave series an overhaul, so compiling blocks should really work 
now. Let me know, if it doesn't.
- Changed system/version/platform, so it's now a word.
- Added new tests.

When compiling blocks, each block instance has its own compiled code. 
And changing at one instance doesn't reset compilation for another 
(which would else add overhead). So:

w> s: [1]
== [1]
w> do s
== 1
w> t: tail s
== []
w> insert t 2
== [2]
w> do t
== 2
w> s
== [1 2]
w> do s
== 1


APPEND doesn't change at the block instance, so APPEND doesn't reset 
compilation.

Block compiled state will be reset by functions such as INSERT and 
REMOVE. And if the block is set to another location (NEXT/BACK with 
call-by-word for example).

What would be World's equivalent of this:    with: func[obj body][do 
bind body obj]

You found a bug! :) Uploading fix ...

@Oldes, fix uploaded. Get world_* again.

And the WITH function would then be:

with: func [obj body] [do compile/at body obj]

I added WITH to rebol.w

APPEND not resetting compilation while INSERT resets compilation 
is kind of weird (even though the implementation details leading 
to that decision may be understandable).

A helper function to reset compilation state would probably be helpful.

(Not sure if just calling COMPILE w/o context after modification 
would always be the same. Will have to think about it a bit more, 
but I have a hunch that it is not.)

Yes, I agree to some degree. If APPEND was a native, it would really 
make sense (I guess). We could add a compile to the APPEND mezzanine.


I think, the compilation reset would just be COMPILE. Don't you think?

No, I don't think so. The result will differ if something used in 
the block is redefined _after_ the block was modified.

A basic example:
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

That code leads to an error, if c is compiled before f is redefined. 
The error system isn't very good atm., and I'll probably work on 
that next.


I need more experience with World and more examples to say, if a 
compile reset is a good idea.

You can also do it the other way round, then it won't lead to an 
error (at the moment, that is :)

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

Correct. World is not designed to cope with such cases, where words 
changes from functions taking arguments to passive non-function values, 
or if number of arguments changes to a function. To change the behaviour 
of the c block, a compile is needed. So question is, if that compile 
should be executed by a COMPILE call, or if the compile state of 
the block could be reset, and in this case, it would be compiled, 
the next time, it was executed with DO.

Currently we have a way to force (re)compilation (with COMPILE), 
but we don't have a way to drop previous compilation.

The example above illustrates that for the most general case, both 
are needed.

Right, and we have to figure out, if we really need that.