World: r3wp

@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

Just to say that the R3 model of a function is better than R2 in 
that case

Yes, sorry for the snark.

Block sharing can also occur through code blocks passed as parameters, 
though.

t: [...]
f: func [c t f] [either c t f]
f ... t ...

yead but it"s generaly not the blocks which are executed (data only)

But you could of course "localise" those blocks (or at least their 
compiled code) upon function compilation.

that's my point ;-)

Mine as well :) That's certainly one of the "weird semantic corner 
cases" I'm talking about :)

But keeping a "compiled block pool" attached to a function is certainly 
a very interesting idea.