World: r3wp

It also renders JavaScript, and XML, and CSV, and SMS, and Email, 
etc.

But Rebol does the rednering.

yes, I always see html as a "presentation" layer .... one of them 
...

We do too.

An annoying one at that.

Would much rather render to RebGUI for example.

When Rebol.plugin works on all browsers, that would become a reality.

btw - do you know what Carl means by "browser integration" project 
he mentioned ?

is that plug-in related? or something else?

Hmmm, I will assume plugin related, but in fact I don't know.  I 
will ask him at some point.

ok, thanks .....

On Rebol plugin.


Opera 9 (still in beta) have a nice way of implementing their version 
of widgets.


Technically, it is no breakthrough. But, the way they place the 'Opera 
Widgets' is similar Mac's dashboard.

The 'Opera Widget' tab' will sit on top of your desktop so long as 
Opera is loaded.


So, even if you have FF open, etc, there will still be this litte 
tab on your 'title bar'. Clicking it will show the various widgets 
you have.


I would think if Rebol could be integrated with the browser in this 
way...it will be a plus point.


Opera test builds can be obtained at http://my.opera.com/desktopteam/

manual resync...

denismx, when I've taught REBOL to people, even people who are already 
familiar with other programming languages, it has been helpful to 
make the distinction between the REBOL language and the dialect engines.


REBOL is really a data model and related syntax, and a bundle of 
library functions that manipulate data in this model. A dialect is 
really a semantic model for interpreting this data, like what people 
think of as a language in real life. A dialect engine is a set of 
library functions that think of the data in the same way - I know 
this sounds anthropomorphic, but it makes it easier to explain REBOL 
if you think of the different dialect engines as entities that are 
acting on a set of commands you are giving them. You can even use 
role playing to demonstrate this, having one of your students act 
out the part. It also helps to name each of these models after the 
main function that implements them - otherwise people might not get 
the distinction between them and REBOL as a whole.


There are some functions that only deal with the REBOL data model 
and don't really do anything with the data other than translate it 
from or to some concrete syntax. It is best to group these functions 
by the syntax they implement - the group that implements what people 
normally think of as the REBOL syntax is LOAD, SAVE and MOLD.


When teaching REBOL dialects I usually start with what I call the 
DO engine, what people normally think of as the REBOL language. DO 
is a stack machine like Forth, but it uses a prefix syntax to make 
it easier to use (by making DO dialect code more resemble that in 
other programming languages). DO also does a simple swapping hack 
to implement inline operators, which you will have to demonstrate 
so that your students will understand DO's operator precedence or 
lack thereof. DO always works on REBOL data: If you pass it a string 
or file that contains REBOL syntax code, DO will call LOAD to convert 
it to REBOL data - this is an important distinction to make so that 
your students can distinguish between the data and the processor 
of that data. There are many functions that depend on DO to interpret 
their blocks of "code", such as IF, WHILE, FOR, etc. It is important 
to note that these are just functions, not "syntax". DO's only syntax 
is the predefined operators that DO swaps (these are effectively 
keywords because of how the swap is implemented), the word/set-word/get-word 
difference, the interpretation of paths and the precedence of parens. 
Everything else is a function.


There is also the PARSE engine, a rule-based recursive-decent parser 
with limited backtracking, that implements three dialects (simple 
parse, string parse and block parse). These dialects actually have 
keywords, as well as an entirely different execution model. Also, 
there is the View engine, which implements the LAYOUT and DRAW dialects.


Refering to these engines as state machines isn't helpful, because 
the distinctions between their execution models, or whether they 
even have execution models, is important for distinguishing between 
them. You need to use the higher-level terms like stack machine, 
composition engine and such.

I hope this helps!

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 ...