World: r3wp

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.

It may or may not actually be checking to see if the word exists 
but the effect is the same...

I keep trying to explain this but haven't really found the right 
words for it YET...

Jaime, yes I agree that rebol implements context internally. You 
mention the idea of a lookup chain or initialisation chain, if you 
mean that such a chain maintains some relationship between your ancestor 
and descendent objects then no I don't think so.  Once the context 
function has finished being evaluated then the idea of ancestor and 
descendent is finished. The two objects stand equally at the same 
level, no relationship between them exists even internally, except 
that you might consider them to be associated because they share 
some function value or other values.


As Anton has said, words know their context. I tried to put it visually 
by saying they have a colour and that colour identifies their context.

I guess what I'm saying is that the idea of a lookup chain is not 
needed to understand rebol. We only need to know that a rebol word 
is a member of some context and that association between a word and 
its context can be changed by functions like Context, Bind, Func 
and Use when they are evaluated.

Have a look at the In function. The In function returns a word. The 
word that it returns still has its original association with the 
object context.

name: "black"
red-ctx: context [
	name: "red"
	green-ctx: context [
		name: "green"
		blue-ctx: context [name: "blue"]
	]
]
names: reduce [
	name
	in red-ctx 'name
	in red-ctx/green-ctx 'name
	in red-ctx/green-ctx/blue-ctx 'name
]


; Names is now a block that contains four words of different colour 
(context binding)
probe reduce names

For fun this next example is totally equivalent.

name: "black"
red-ctx: context [name: "red"]
green-ctx: context [name: "green"]
blue-ctx: context [name: "blue"]
names: reduce [
	name
	in red-ctx 'name
	in green-ctx 'name
	in blue-ctx 'name
]


; Names is now a block that contains four words of different colour 
(context binding)
probe reduce names

Except of course for that fact that red-ctx does not have a field 
green-ctx!

Ammon. On your point 3 above. "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."  No, it doesn't 
work this way. There does not need to be runtime searching.

It is more like this...

Look at my nested context example, and focus just on the 'name words.

(1) When the first context function is encounted during evaluation, 
it has a single argument a block - which happens to contain 5 values. 
A set-word, a string, a set-word a word and a block.

(2) Now when this first context function is evaluated it creates 
a new context, and binds to this context the all 'name words it can 
find in the block and nested blocks. To visualise this imagine all 
the 'name words including within the nested blocks have just changed 
Red.

(3) After this colouring of the words, the block is evaluated (as 
in DO) so that at some point the second reference to the Context 
function is evaluated.

(4) Like the first, it colours the name words in its block and nested 
blocks - let's say to green.
(5) The final level is blue of course.

(6) By the time all evaluation is finished the 'name words have the 
appropriate bindings (colours). Conceptually, maybe even actually, 
the innermost 'name word has had its binding (colour) changed three 
times, the second level one twice, and the highest once.


In this way there does not need to be any runtime searching for "parent" 
contexts, because the words themselves maintain the references to 
the appropriate contexts. The Set function does not need to search 
it can see the binding (colour) already.

Heh, I guess I'm hard to understand. ;~>

This particular subject has come up a number of times since I started 
playing with REBOL in 2000 but for some reason I can't seem to make 
the point that I am attempting to make everytime it comes up.  I 
think I'll leave it alone now...

lol - the context of our understanding keeps changing ;-)

Something like that. ;-)

Ammon: "1. It has to be happening during runtime there is no compiling."
load-time and loop-time then? ;)

ammon: "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."

Thats the important point: there is no reverting :) and so there 
is no need to keep track of parent-contexts.which is quite clever 
:)

What is the quickest way to transform this :
	[ ["a" 11 #toto] ["b" 28 #titi] ["c" 3 #pim] ]
into this :
	[ "a" 11 #toto "b" 28 #titi "c" 3 #pim ]
???

Fastest, I don;t know.  But this works:
xx: [ ["a" 11 #toto] ["b" 28 #titi] ["c" 3 #pim] ]
loop length? xx  [append xx xx/1 remove xx]
 head xx
== ["a" 11 #toto "b" 28 #titi "c" 3 #pim]

Close to being fastest:
xx: [ ["a" 11 #toto] ["b" 28 #titi] ["c" 3 #pim] ]
x: copy []
loop length? xx [insert tail x xx/1 xx: next xx]
x

A time function to measure the speed of code:

time: func [:f /local t0] [t0: now/time/precise do f now/time/precise 
- t0]

Now you can do e.g.:
time [loop 40000 [
xx: [ ["a" 11 #toto] ["b" 28 #titi] ["c" 3 #pim] ]
x: copy []
loop length? xx [insert tail x xx/1 xx: next xx]
]]

foreach b  [ ["a" 11 #toto] ["b" 28 #titi] ["c" 3 #pim] ] [append 
 [] b ]

If you want faster execution you should initialize the block [] outside 
the loop

Has onyone manged to use Core with an iSeries (AS400) FTP server.

I have had no success at work .... it trying to read a folder in 
the IFS (Integrat File System) but the server returns a FTP error 
250.

(I dont have all the details on me at home).  Now looking at the 
FTP error numbers 250 is a normal return code, so I dont understand 
why I am not getting any information back.

I am using core 2.6 under winXP .... and connecting to a Linux server 
is working OK.

Didec, i should do: parse b [any [h: set x skip (h: change/part h 
x 1) :h]]

Philb, try my ftp client

On your website Romano?

yes

i it does not work, try the nlist flag

Thanks all

nlist flag?

I will give your handler a try tommorow ... thanks Romano

Is there a load path for the 'do function?

You mean like a PATH variable in a dos or unix shell environment 
?

As far as I know, do only looks in the current directory (as returned 
by WHAT-DIR) for relative files.

okay, that's what I thought. I was hoping that I'd just missed something.

It would be easy to roll my own "include" function. I might try that 
as a little project.

Yes, it's relatively easy. Just don' t think it's going to be quick 
:)