World: r3wp

That's definitely true, but I see value in trying to determine which 
functions are used the most often, to teach those first.

Well, I've just manually extracted the rebol functions from my latest 
script demo-virtual-face.r (as posted in the View group), so I'm 
looking at those. I've excluded layout and draw dialect keywords. 
The order in which the functions appear is interesting. I have some 
duplicates. So now I'm analysing..

Also it's clear to me that the importance of a function is not always 
related strongly to it's frequency of use. Take VIEW for example, 
not used that much, compared to other functions, but without it you 
cannot open a window ! (You can, actually, in other ways, but VIEW 
does a lot of work. Mmm... another way to assess importance of a 
function, the length of its source ?)

Ok, so here's my frequency table:
    6 compose 
    5 as-pair 
    5 func 
    4 do 
    3 show 
    2 all 
    2 copy 
    2 find 
    2 form 
    2 get 
    2 in 
    2 pick 
    2 print 
    2 to-image 
    2 use 
    1 * 
    1 + 
    1 - 
    1 <> 
    1 = 
    1 append 
    1 bind 
    1 center-face 
    1 change 
    1 clear 
    1 context 
    1 do-events 
    1 either 
    1 first 
    1 foreach 
    1 if 
    1 join 
    1 layout 
    1 load-thru 
    1 make 
    1 mold 
    1 object? 
    1 reduce 
    1 remold 
    1 remove-each 
    1 repeat 
    1 second 
    1 select 
    1 to-pair 
    1 to-path 
    1 view

To create the above list, I just read my source script file and wrote 
each word as I came across it, manually, into a new script file. 
Then I ran the following code:

blk: [
* 
+ 
- 
<> 
= 
all 
all 
append 
as-pair 
as-pair 
....
]
blk: sort blk
ublk: unique blk
hist: copy []
foreach word ublk [
	count: 0 forall blk [if blk/1 = word [count: count + 1]]
	repend hist [count word]
]
new-line/all/skip hist on 2
sort/reverse/skip hist 2
write clipboard:// mold hist

Gosh there are so many ways to analyse !  There's also the issue 
of how often some functions are called, not just how often they are 
written. For example: I have not included the names of my own functions, 
whose source is written once, but used many times, effectively hiding 
the importance of the words used inside from this analysis technique.

I've added another much longer file, so my frequency table now looks 
like this:

47 if 
    35 all 
    17 func 
    14 find 
    13 in 
    13 not 
    13 print 
    12 do 
    12 either 
    12 get 
    10 = 
    10 next 
    9 clear 
    9 exit 
    9 insert 
    9 pick 
    8 compose 
    7 any 
    6 foreach 
    6 mold 
    6 tail? 
    5 - 
    5 as-pair 
    5 last 
    5 none? 
    5 object? 
    5 paren? 
    4 head 
    4 reduce 
    4 show 
    4 while 
    3 break 
    3 copy 
    3 remold 
    3 remove 
    3 same? 
    3 tail 
    3 use 
    2 * 
    2 + 
    2 <> 
    2 context 
    2 forall 
    2 form 
    2 make 
    2 prin 
    2 return 
    2 set 
    2 to-image 
    2 to-time 
    2 view

Such analysis as this also ignores the interesting ways that words 
are related in patterns of usage. (eg. [get in] is used quite often)

Anyway, I hope the above list can help to get a rough idea of which 
functions should be studied first.

- maybe examine multiple scripts, and count in how many a word is? 
Then 'view would count high, even if used once. Words occuring in 
every script are important.

- "choose the task instead" - good idea. Make a list of tasks and 
list required   words. could be in that 15-30-range

the better way to gauge useage is not by frequency within one script 
but by useage amongst many scripts... where useage within that script 
many times still only counts as one.  I'd use the rebol.org site 
to scan scripts from any given group and put usage from them.  Thus 
networking would score view as almost 0 where gui would place view 
as the most used word (in every script)

and using rebol.org you could even classify by advanced, and separate 
words being used more often in 'advanced or intermediate work.

That would improve things I think.

Also it's clear to me that the importance of a function is not always 
related strongly to it's frequency of use.

This is why you need the Genus.


View would be a root, while many string commands would be all gathered 
at the end of some branch.  This becomes really easy to see when 
you present the data that way.

It's not so simple, because there are many ways to hierarchically 
arrange the words, looking at them from different aspects.

then its a good test for the associative DB I am about to start working 
on.  :-)

I was looking for a good and simple data set to organise.

(I have been REBOLing full time for a while and yess many things 
are moving ahead :-)

You could make trees where the grouping is by the words that follow 
or precede a word. Expressions, basically :-)

we can have each atom of information relate to any other atom based 
on rules we define... once the dataset is parsed, then you end up 
with a complex modeling of all related data which you can query and 
search trough quite quickly.

I am trying not to open too much on many of my current projects... 
but this is going to be co-developped while I'm doing liquid.

I'll give a shot at sorting out all of rebol.org once I get basic 
capabilities going and report back here, when its done.

I think just the list of natives would be a good start then use the 
source for the mezzanine functions as excersize of what can be done.

Classify the native words from easy to advance. I assume everything 
else can be generated using the native words.

op! action! native!  then probably function!

Although the "choose a task first then learn what needs to be used 
to code it" approach is fine in many circomstances, in a 45 hours 
course, the student ends up knowing how to code a few tasks (hopefully 
more than one, but not necessarily), but often has a very hard time 
transferring this knowledge to other tasks.


So I think a better "generalist" approach would be to categorize 
generic tasks, like "file manip"', "math", "iterations", "series", 
"network sharing of data", ... and identifying just a few native 
words category that are enough to solve all or most problems given 
in those categories.

Example problems I would give my students to solve would look like 
(to be adjusted according to the native word set retained):


Using iteration, draw a 19 line isoceles triangle (concepts of looping 
not obvious for beginners, but essential to grasp early)


Find all prime numbers lower than a given one, using previously found 
primes in the process to speed up the search.


Given a list of adresses, get the files and identify which ones have 
a given information on them (elementary parsing)


... Things like that. Diversified enough to give a good feel of what 
programming can solve while gaining basic skills (data stores, interation, 
maybe recursivity, various control structures - not necessarily all 
of them, operators, native functions and user defined functions, 
input and output, ...)

The pdf manual "Rebol Essentials" comes close to that. It seems to 
be a good starting point.

Another idea someone proposed in this thread which is very interesting 
if it is possible, is tracing a hierarchy of all the native Rebol 
word. If such a structure really undelies the whole or part of the 
400 word list, then this would be a powerful conceptual tool to aid 
in building learning "environments" for the language.

I think it depends a lot on your audience. You said they had no previous 
experience in programming, but are they computer science students 
or humanities, or engineering?


Their are many things to teach at once; computer science concepts, 
Rebol concepts, how to program, etc. I guess you would also have 
to settle on a single programming paradigm to start with. If your 
audience are hunamities students then the not so simple concepts 
such a "programming language" and "program" (leading to "syntax", 
"semantic", "type") are very important to understand properly first. 
Then you have "expression", "evaluation", "subprogram"" etc. (leading 
to "values", "binding", "function"). I think all this can be done 
through meaningfull practical example built russian doll style.

When I said native, I did mean op!, action!, native! which source 
classifies as native.

There are about 270 in View but the op! are duplicates of some natives, 
and some natives are for efficiency and can be rewritten using the 
other native words. I guess I like looking at Rebol as a Forth language 
with very good and standard I/O support.

Jean-François: one of the courses I teach is an introduction to programming 
to science students. Some of which will follow two more courses in 
programming, in the same language. Over the years, I've done this 
in Fortran, Pascal and now C++. At one time the first two courses 
were given in Python and the last (which I was giving), in C++. We 
decided that it was better to give all 3 in the same language. I 
didn't think Python was a good choice.

I'm now giving the first course (and maybe all 3). I'm exploring 
the possibility of opting at some time for Rebol, if I can break 
down the language into subsets that are "easily" learned and that 
offer useful tools for some large category of problems. I did'nt 
find any tutorial that seems to be quite there yet. 

Of course, the language is not the only thing taught. Basic programming 
and computer science concepts are also taught. But these can be taught 
independently from the choice of the language, for a large part. 

Rebol is my preoccupation. Some languages need a very lot of reading/learning 
before you can start to use it for solving problems with them. Maybe 
this is the case for Rebol. But I'm not sure yet. My hypothesis is 
that nearly everyone has learned Rebol by reading the Core manual 
and looking at examples in tutorials. It's ok to do it this way if 
one chooses so. But the teacher is expected to devise smoother paths 
for the learning process.

If I can engineer such a learning path, even if we never switch to 
Rebol for our classes, I'm sure that it would help enlarge the Rebol 
community. So I'm getting more interested in this project as I'm 
going along. It is not an obvious endeavor.

I agree, starting with polygons and graphics is great for instant 
visual feedback at the beginning.

i'd say the most important rebol native is INSERT. (even print is 
insert system/ports/output under the hood)

ah! "insert". I would not have thought so. Will remember that while 
picking native words...

Denis : You should maybe contact Gerard Cote on the mailing list. 
I believe he has been using Rebol in teaching introductory programming 
for a while now. He might have interesting pointers.


Also I would be curious to know if you have ever considered using 
Scheme for your courses. There are great ressources such as PLT Scheme 
and their book "How to design Programs" or "Simply Scheme" by Harvey 
and Wright. I think the content could be adapted to a curiculum based 
on Rebol

A few ideas were collected here as well 3 years ago http://www.compkarori.com/vanilla/display/Rebol+School

tks for the link Graham. And there is a mention of Gerard Cote in 
there too, Jean-François.

Actually, I'm not trying to figure out how to introduce programming 
concepts, or computer science in general. I already have a lot of 
stuff on that since I have been teaching this for 20 years now. And 
I'm not looking tor a "better" language to teach, even though I have 
given a look to Scheme.

What I want to develop is a "better" approach to learning Rebol, 
for non-programmers mostly. I'm really focusing on Rebol, and not 
what should be learned before, nor what could be a better option.

The "Rebol Essentials" is a good start. But I think I can break the 
approach down to still simpler steps. The difficulty I face is not 
having the broad, overall picture for Rebol. I am very conscious 
this limits my ability to make the best choices for the moment.

Here is what I figure would be a good starting point, at the present 
level of my knowledge:

First concepts: values, words (at a basic level), blocks (later on 
: functions)

First natives: print, arithmetic operations, the simplest control 
structures (conditional, for loop, while loop)

Then reading data somewhere and some simple parsing techniques: find 
a string, extract from one point to a second and saving the data.

I have the feeling that would be a very good starting point. I'm 
a little hazy on what is offered for parsing in Rebol at the moment. 
I'll look into that next. I think that once you have read a file 
into memory, it is in block form and you can use natives like "first", 
"next", "find" and so on on it. If so, then I would be going that 
way for sure.