World: r3wp

Yes, it does. ;-)

Each word "knows" which context it lives in. When you make a new 
object, the top-level set-words are BINDed to it. So each word knows 
its binding.

I think Ladislav used to have a nice example where each of the words 
in this block could refer to different values, because they were 
bound to different contexts:   [word word word word]

They all look the same, but just looking at this you cannot tell 
which context each word is bound to.

sounds kinda cool but scary from a code maintenance perspective.

Bah.. We use this feature all the time without thinking about it. 
Take a look at this:

context [v: 12 print v]

(it prints "12" to the console :)

Now luckily for us, 'print was not bound to the new context. It "remembers" 
its context is the global context. That's how we can get its value 
(a function) to actually do something.  The set-word, v: ,  on the 
other hand was bound to the new context, so we know it won't affect 
anything outside.

>> b: [] repeat i 5 [use [x] [x: i append b 'x]]
== [x x x x x]
>> reduce b
== [1 2 3 4 5]
>> same? b/1 b/2
== false

you can think of a word as if it was a block that could only keep 
one element. so each word keeps its value, in a similar way as each 
block keeps its values. (this is not 100% correct, but maybe it helps 
understanding)

Ah yes, this one is tricky !

but I suppose the same line must be done before the block reducing, 
as "same? 1 2" can't answer true.

...the same? line...

Ups, sorry. Block is reduced but not reassigned to B

I always wanted a way to dump all contexts a word is defined in: 
like "dump-context myword" and get a list of named and unnamed contexts. 
Anamonitor can do this.

>> split-path %/c/test/bla.txt
== [%/c/test/ %bla.txt]
>> split-path %/c/test/bla/
== [%/c/test/ %bla/]

Isn't this inconsitent? I think the last should give:
== [%/c/test/bla/ none]

yes Robert anamonitor can do it  (i do not remember if the last released 
version does it, but my version does it :-)

and yes Robert,  i do not like split-path behaviour in many cases 
(see RAMBO discussions about this), but i do not think that your 
request is good, from my pov 
	%a/b/
should give
	%a/   %b/              = the dir b inside the dir a
or
	%a/b/   %./	     = the current dir inside the dir %a/b/

this is inconsistent with:

	>> split-path %./ ; == [%./ none]

but i think the last behavior should change in this

	%./    %./

none should never appear in a splith-path result

Well, maybe split-path is not so useful sometimes, but at least it 
says what it is doing :) I think what we want most of the time is 
the dir-part and the file-part of a path (actually these are functions 
I use). I think they are more useful in general. The problem is in 
coming up with a good name to describe this behaviour..... maybe: 
   to-dir-file-parts %my/path  ;== [%my/ %path]    ?

As you said: file-part, dir-part

Does rebol has some form of inheritance? Well not according to the 
docs. But when intializing within context there seems to be an initialization 
chain that look like a bit like inheritance to me.

o: context [ 
    a: 0 
    b: none 
    o1: context [
        a: 1 
        c: 3 
        set 'b 2 
        o2: context [
            set 'b 4 
            set 'c 5 
            set 'd 6
        ] 
    ] 
]

O is an object of value: 
   a               integer!  0 
   b               integer!  4 
   o1              object!   [a c o2] 

>> ? o/o1
O/O1 is an object of value: 
   a               integer!  1 
   c               integer!  5 
   o2              object!   [] 

>> ? o/o1/o2
O/O1/O2 is an object of value: 

>> d
== 6

The slots got the last value set by the child context of each parent.

Uhm...  But that isn't inheritance, it is simply context.

o: context [

A new object begins to be created.

I should say, it is context that allows sub-contexts.  It's more 
of a hierarchy...

The top-level of the spec block is scanned for set-words; in this 
case, there are three ( a:  b:  o1: ). These three words are added 
to the newly forming object. The spec block is now scanned *deeply* 
and where one of those three words ( a b o1 ) is found, they are 
bound to the object.

Using  "set notation" (eg.  context [ set 'b 4 ] )  does not attach 
'b to the object. It must be a set-word (eg.  context [ b: 4 ] )

So, in the creation of your object o2, 'b and 'c are found to have 
been previously bound to o and o1, respectively. Setting them does 
not modify the binding. 'd was found not to be bound to anything 
so it was set in the global context. (people use this last trick 
to "export" functions or values from a context).

Rebol's elegant use of context is really powerful.

; Jaime try comparing your example with this:
o: context [a: 0 b: o1: none]
o/o1: context bind [a: 1 c: 3 set 'b 2 o2: none] in o 'a

o/o1/o2: context bind (bind [set 'b 4 set 'c 5 set 'd 6] in o 'a) 
in o/o1 'a
; I think you'll find they are equivalent.

Imagine context as a "colour" of a word (btw would be nice to see 
in an ide).

Then, in your example, the first context function changes the colour 
of all the a,b and o1 words to "red" say.

Then the next inside context function changes a,c, and o2 to green.

And finally the inmost context function doesn't get to change anything 
because there are no set-words to process - if there were they would 
have been made blue of course ;-)

By my analogy, the b, c, d of the inmost block would have the colours 
red, green and black - black being the global context.

Normally, all words start as black when they are loaded into REBOL.
Colourful analogy don't u think?

I don't think there is a hierarchy of contexts.

In Jaime's example there is a hierarchy of blocks (nested). As evaluation 
proceeds, the words in those blocks get "painted" different colours. 
That's why my code using bind ends up with the same binding of words 
even though I didn't have the same hierarchy of blocks  - I simulated 
the same order of binding.

Brett I aggre that there is hierarchy of blocks. I guess what I was 
getting at is that rebol implements context  internally using some 
sort OO technique to keep track of the assignments. In this case 
the OO technique is  lookup chain.

I think that is correct, remembering a discussion with Carl Sassenrath 
a long time ago.

Brett, well said.  That is what I was trying to say but couldn't 
put it to words for some reason...

Not a chain, a "compiletime" replacement.

red: context[a: 'red blue: context[a: 'blue]]

'a is first bound to 'global, then to 'red, then to 'blue (going 
from outer to inner block). then it stays blue until you bind it 
again.

(the 'a in [a: 'blue] not the others. better remove them..
 red: context[ blue: context[a: 'blue] ]

Yes, but you're using a set-word! which doesn't properly demonstrate 
what we are talking about.  Change [a: 'blue] to [set a 'blue] and 
then you have it. ;-)

What did i not get? Jaime: "that rebol implements context  internally 
using some sort OO technique to keep track of the assignments. In 
this case the OO technique is  lookup chain." in your case 'a is 
never recolored.

and for demo my first example was right. trying again:

loading: all 'a in [red: context[a: 'red blue: context[a: 'blue]] 
] are colored global

creating outer context: all 'a in [a: 'red blue: context[a: 'blue]] 
are colored red
creating inner context: all 'a in [a: 'blue] are colored blue.
now all 'a have their right colors :)

lookup-chain
 sounds like runtime-searching to me.

1. It has to be happening during runtime there is no compiling.  
2. I don't understand your second attempt there.

3. If you use a set-word in a context then that word becomes part 
of that context.  If you use SET then it reverts to the context's 
 "parent context" or the context in which the context itself is defined. 
 If the word exists in that context then it is set there, if not 
then it grabs that context's parent until it has made it to the global 
or top level.  If the word doesn't exist globally then it is created...

I missed a step there...  If you use SET then it first checks the 
context of the word if the word has a context then it attempts to 
assign the word there.  If the word doesn't have a context then it 
uses the current context.