World: r3wp

Reichart - have you ever looked into stuff like transformations? 
If XML was all that easy as you suggest, how is that we don't have 
proper SAX or DOM parser in rebol - those supporting libs are sometimes 
larger than Core itself - I wonder, if it was intention of its creators 
......

Yes I knew altme was 100% Rebol. Don't know about Qtask though.

Qtask  is not 100% in rebol, but it is 100% rebol inspired :-)

Qtask is not 100% Rebol?

well, wife is calling for dinner (EST here). Will check back later. 
Very usefull discussion. Tks for all the help. Very encouraging. 
Lots of reading to do! :-)

Reichart - it uses html, so no?

have a good dinner!

Used HTML, no, it renders "to" HTML.

time to move home too .... 18:30 here, enough of "work"

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)