World: r3wp

Tks Brian. Yes it helps. I will print this overview and use it as 
I analyse the Rebol universe in the days to come.

denismx - look up Devcon 2005 videos and Gregg's presentation on 
Dialects ... nice explanation of Logo dialect and iirc I even saw 
somewhere (dunno if in the same presentation) Excell dialect ...

The other main thing that will likely trip you up is understanding 
how words, contexts and bind, together serve the role that variables 
or symbols serve in other languages. I could go on about that, but 
you would be better served by reading the extensive articles that 
Ladislav, Gabriele and I have already written on the subject.

Don't forget Forth in the heritage list! Lisp/Logo and Forth are 
key design ancestors, for lists/blocks and words, respectively.

So, the main things I think of as far as basic concepts are:


1) Everything is data; sometimes that data is evaluated and things 
happen.


2) Everything lives in blocks; there are series operations that you 
need to understand in order to manipulate them.

3) Everything is data.


4) Words are very important; not only knowing when they are evaluated 
and other technical details, but also how you choose them so they 
work together well.

5) Everything is data.

Words, contexts and bind... : Ladislav, Gabriele and BrianH articles. 
I suppose I will find those articles on rebol.org? I will look them 
up and read them. And the presentations on Dialects... although what 
I understood about that was that one could make up dialects for a 
particular use. If so, not sure it would help in the ingeneering 
of a "better" teaching/learning approach for the language.

Did you notice http://en.wikibooks.org/wiki/REBOL_Programming? My 
Bindology article is: http://www.fm.tul.cz/~ladislav/rebol/contexts.html
(I guess it may earn a title of the most unreadable article written 
on the subject :-)

There is not variables, there are just values, and symbols associated 
with the values.
 I don't buy this for 100%, because:
>> a: b: 4
== 4
>> a
== 4
>> b
== 4
>> b: 3
== 3
>> a
== 4

If it would be than I would had to use COPY to keep the value 4 for 
'a.

It has implicit copy semantics implemented.

I can't follow your logic:

>>a: b: 4

Both symbols a and b "point" to the value 4

>> b: 3
symbol b now "points" to the value 3.

Peter, Robert, you're both wrong, an a sense. The "pointer" metaphor 
is too lowlevel and probably misleading; but, Robert's example above 
has nothing to do with "copy" semantics.

maybe this thread can be useful: http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlKVVC

there are other similar threads on the ml

I agree with Robert there is an implict copy of data in b: 3, the 
value 3 is copied from the user block to the context data block; 
words always refers to value in context data block and not to value 
in user block.

Romano, that's what I meant but didn't wrote so clear. Thanks for 
helping out.

Peter, yes, but you could read (but as Gab said, pointer semantics 
isn't correct anyway)
a: b: 4

'a pointing to 'b pointing to 4


and if I know change 'b to point ot something else, 'a still points 
to 'b.

Well, I would read it like:

'b pointing to 4

'a pinting to the return value of (b: 4), which would be a direct 
pointer to 4

So you get 2 parallel pointers to 4, not 2 chained pointers.

Symbols can only bind to values. The pointer metaphor is just easy 
way to expaning things but it is not correct.

if you use the "value slot" concept everything should be clear. blocks 
are arrays of value slots; the data in a context is an array of value 
slots too.

a: b: 4 -> 4 is evaluated -> result 4 -> 4 is copied to slot of b 
in the context of b -> result 4 -> 4 is copied to the slot of a in 
the context of a -> result 4 -> console display 4

a points always to the same slot in its context, b points always 
to the same slot in its context - the content o these slot is changed 
by copying the value 4 in them

And when you bind a, you make it point to another context with another 
slot in it.

That's the difference between binding and assignment: Assignment 
changes the slot, binding changes what context the word points to.

I'll probably find this answer in one of the articles I was pointed 
to, but the question comes up: Binding creates a slot in a given 
context in terms of memory allocation? If so, when is it released? 
Is there some kind of garbage collector in the Rebol runtime? These 
questions are probably not relevant since words are not pointers 
anyway, from what u guys are saying above.

Maybe I should ask: How are words implemented in Rebol?

Many thanks for the slot explanantions. May i seek a little further 
understanding by asking:


Is it the result of the evaluation of  4 that is copied to the relevant 
slots?

Does this hold true for all values, even series?

Yes, there is an automatic garbage collector. (you can force it with 
RECYCLE)

Values are released when there are no more references to them (and 
the GC decides it's time to do a recycle).

Words, however, even though they are values, cannot be destroyed. 
If you go into the console and type some random words like "aklsdf", 
you can see them at the end of  first system/words, and they will 
never disappear from this list, even if the words are unset.

A word is basically a value that can be put in a value slot. This 
value includes a pointer to a symbol and a pointer to a context.


A symbol is like a string that is only stored once. The symbol that 
is pointed to by a word is the same symbol (same chunk of data) as 
that pointed to every other word that is made up of the same characters 
as the word (case-insensitively).


A context is like a map from symbols to value slots. When you create 
a context it has the specified set of symbols associated with it 
and each one of these symbols has an associated value slot. When 
you bind a word to a context, you change the context pointer of a 
word to point to the context. If you try to bind a word to a context 
that doesn't include the word's symbol, the bind fails silently and 
the word is unchanged. With the exception of system/words, all contexts 
are of fixed length once they are created (for now).


If the word's context pointer is not set, the word is considered 
unbound. If the corresponding value slot in the context the word 
is bound to is supposedly empty, the value slot really contains the 
unset! value, and the word is considered unset.


(Current implementation) Every word you create is added to the system/words 
context, which expands to include it if it isn't already there. Currently, 
system/words has an upper limit of 8000 words. This effectively means 
that the words your script uses must not exceed 8000 unique symbols, 
including those used by the runtime.

I've made a document here that kind of explains words and values. 
It doesn't explain the same word in different contexts though.
do http://www.lexicon.net/antonr/rebol/doc/rebol-values.r

Currently, object! and function! types have contexts associated with 
them, and some natives (such as USE) create contexts internally as 
part of their operation.

Anton, my explanation above does cover the same word in different 
contexts. Contexts don't really contain words (except as values in 
the value slots). You can think of a context as a hash full of references 
to symbols and a block (of the same length) that contains the value 
slots corresponding to those symbols. A word is just a value that 
points to a context, and another word can point to another context, 
even if both words also point to the same symbol.

Peter, series values are really a pointer to the series data and 
an offset. When you assign a series value to a word, that pointer 
and offset are copied into the value slot that is currently associated 
with that word (until it is bound to another context). The actual 
series data pointed to is unchanged, though.

An integer value like 4 is actually contained in the value slot rather 
than pointed to by it, so when you insert a 4 in a block or assign 
one to a word, it is copied into the new value slot. Value types 
like this are called immediate values.

I think that it would be good to have visual drawing - sentences 
as "symbol that is pointed to by  a word" is kind of abstract for 
newbies. And what bothers newbies? When the series is unique and 
not shared. I know cases where I better use 'copy, because I am not 
really sure, what rebol will do ...

I don't know single person, who would not run into troubles because 
of that ... I once even saw Carl's script, where changing border 
of one button changed them all ;-)

I agree about the pictures. Too bad AltME uses variable length fonts, 
or I could do ASCII art. It's a good thing that denismx already told 
us that he is familiar with C++, so I don't have to explain what 
I mean by a pointer or a string here.

I know, nothing against what you describe, I just wanted to point 
out to possible troubles and mistakes by newbies, and am trying to 
find out, how to avoid it ....

I just hope he can translate for his students.

Perhaps we need to make a REBOL-in-REBOL, if only for the sake of 
teaching.

I'm starting to sort the concepts out, cross-referencing several 
explanations. I will have to tone down the explanations for my students, 
obviously. But to do so, the teacher needs to have a very good grasp 
of the language so as not to make faulty reprensentations that would 
work small scale, but not later on when some students progress further 
in the language.

I find its hard to get people to "grasp" REBOL.  in the sense that 
they we all just see a different syntax twist at first.

The single most helpfull sweeping statement for me was "code IS data"

The document "Rebol Essentials" starts with an explanation of value, 
word and block. Seems to be a good starting point. Haven't looked 
at how it introduces the syntax of system words later on. That is 
a crucial part. I want to find a subset of the 400 Rebol words that 
sould and can be learned first, giving the beginner a useful and 
powerful subset of instructions to start programming significant 
small apps.

Yes Maxim. But that is to mystical for teaching purposes.

Actually, since Von Neuman, code is treated as data. You load it 
into memory and process is as a special kind of data.

... so it's a long time ago that this concept is around.

I remember writing a program in Pascal that modified itself either 
in memory or rewriting itself on disk with variations.

not exactly what I meant.