World: r3wp

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.

I am a strong believer that in cases such as this, whatever is helpful 
internally should also be exposed at the user-level.

My personal view is, that it's sort of bad programming practise to 
change number of arguments to a function in the middle of a program, 
or to change a work from meaning a function or operator to meaning 
e.g. a number.


But I think, it's possible to cope with such strange situations, 
because we have COMPILE.

I.e. as INSERT is able to _reset_ compiled state, so should be the 
user.

(Then a mezzanine APPEND could just reset compiled state, and would 
behave identical to INSERT in that aspect.)

Ok. I understand that view. We can reset compiled state now with:

next 'c back 'c
or
c: back next c

Ok.

Something similar for functions?

w> f: func [v][v + 1]
w> f 1
== 2
w> compiled? :f
== true
w> f: make function! reduce [pick :f 1 pick :f 2]
w> compiled? :f
== false

Hmm, that creates a new function, though, doesn't it?

Are compiled references to values or to names in contexts?

(Well, I can just try that myself :)

And I get a malloc error, when doing that a couple of times. Yes, 
crash. I'll hunt that down.

(Well, I can't, as I get a crash immediately :)

:)

World suxx!

Nope :)

I agree with the notion that those particular examples illustrate 
bad programming practice. But re-binding words to different values 
(functions) is possible in World, so I believe it should cope nicely 
with that situation.

I don't think you should keep the compiled block in memory when DO 
is used.

Compiled blocks (including the nested ones) should be linked with 
functions only (whe functions are created).

I don't think it would be a real perf problem  because DO is not 
used that much to execute standard code in an app.
Just my opinion though.

A possibility, but I think that would on the one hand make implementation 
more complex, and on the other would just introduce more semantic 
corner cases.

Such as a block being shared by a function and a global word.

I agree, the compilation of a function would be more complex (because 
of the nested blocks)

Yes, because compiled code would become an attribute of a function, 
instead of just dangling off a block.

Andreas in R3, nested blocks inside a function can't be shared with 
global words.
The body of a function is deep copied before compilation.

This is the #World channel, though :)

np