World: r4wp

so, you'll have to use an external library to do that part

I'm looking into pitching a Rebol programming class to the community 
college here (I'd teach it).  I know of NickA's excellent tutorials. 
 What would you all suggest for a class text.

I found the 'Rebol for Dummies' book quite disappointing for my personal 
use, but it might be good as a course book though. It certainly covers 
a lot of ground quickly. I personally preferred Nick's video series 
http://re-bol.com/rebol.html.Somehow more interesting and easier 
to digest. Just my personal experience.

I also have 'Rebol. The Official Guide' which at 700+ pages is massive 
and way too much. Also, no graphics included, so I would not necessarily 
recommend that as an introductory course book.

Yes, I also have Rebol for Dummies, Rebol: The Official Guide, and 
just about every other Rebol book in print.

I'm currently leaning towards Nick's tutorials right now.

Is the class for new programmers or people new to programming?


If the latter, Olivier Auverlot's REBOL - A Programmer's Guide" might 
suffice.

Full disclosure - I translated the book from French to English.


The content of the book is a little dated by newer than Official 
and Dummies.

by -> but

After looking at 'Rebol for Dummies' again, that is what I'd recommend 
for a community college course. Even if a little dated.

Getting enough copies of the other books out there may be difficult.

@Graham - thank you, yes I'm aware we only have sha1.  It looks like 
OpenSSL, PolarSSL, MD5Deep, cryptlib, and a bunch of others are out 
there.  Have you used any successfully with AWS?

I wonder if the Saphirion guys have sha256 going.

The AWS functions I use have sha256 optional

Bo: There is Viktor Pavlu's "REBOL Essentials" in pdf form.

Here is the link: http://vpavlu.plain.at/REBOL/tutorial/

There is a beginner's level View/VID part too.

PeterWood, caelum and Endo: Thanks for the ideas.  I've seen Olivier's 
book, but I don't have a copy myself.  That might be a good choice.

The book by Viktor Pavlu looks promising.

I used that to get really more familiar with REBOL. It is a good 
introduction, unfortunately it is not finished. The up-to-date is 
less bothering for it is the basics that's covered and those are 
the same still.

Olivier's book is pretty good IIRC.

Hi all, I wrote

https://groups.google.com/forum/#!topic/Rebol/jL55YPQXWW4

to give an idea what are closures good for in R3.

Nobody will use functions anymore after that demonstration Ladislav!

:-D

I should check whether closures are implemented optimally, having 
the source code available.

Hmm, I thought that's what funct is for, but apparently I was wrong 
- funct just seems to make all set-words local, but not passed in 
arguments ...

well, this is something else than what FUNCT does. Making some variables 
local can be useful for closures as well.

Great works Ladislav, added to http://rebol.informe.com/wiki/view/Rebol_3-closure
 wiki

MaxV: one more improvement to the text; I wrote:

c: closure [a [number!]] [func [b [number!]] [a + b]]

, but, actually, I think that

c: closure [a [number!]] [closure [b [number!]] [a + b]]

wold look better (more uniform)

What I am still afraid of is the fact that the "Closure" name could 
scare beginners looking sufficiently "unfamiliar" and "exotic", while 
I think that what *should* scare beginners as far as the behaviour 
is observed is actually "Function".

When all these renaming issues are discussed I think that it might 
make sense to think about the name in this context as well.

I agree that the name "closure" is not user-friendly. Also, I wonder 
if it shouldn't be the default function constructor (also thinking 
loud for Red). I'm still unsure about that though.

Certainly the series copy trap is the one beginners will fall into 
most. Higher order functions won't be in their code, probably until 
they are comfortable with 'closure.

...but the GUI example should be in the repertoire of beginners, 
don't you think? (and it even "caught" Cyphre, so he asked me how 
to do it properly using function, so I had to tell him: "don't")

Agreed with both of you on naming. Now is the time to consider what 
to change in R3 and what to use in Red. 'Closure has meaning beyond 
Ladislav's current examples. Do we name things for new users and 
novices, or experts? For me, name things clearly, and supplement 
with docs if the names don't match expectation.

On the GUI, yes, perhaps.

The "series copy trap" is what makes me hesitate about making closures 
the default function constructor. I think it should not be a "trap" 
in the first place, it is just undocumented, while it should IMHO 
be very clearly explained in the series chapter. Understanding how 
literal series behave is an important step in understanding Rebol.

Doc +1

In this case "function" obviously does not match expectation, while 
"closure" matches expectation for "function", otherwise looking too 
"scary" to provoke some of its own.

Yes. The question for me is why function doesn't work, since I haven't 
done any R3 GUIs yet.

That is, do we address it in the implementation or naming (e.g. alias 
closure as async-func), or in docs that explain why it doesn't work.

The question for me is why function doesn't work

 - actually, function in R3 works better than in R2! However, that 
 still is far behind closure.

Ladislav: "** Script error: a word is not bound to a context. -That 
is actually better than what you get in R2" Why is that?

This is what you get in R2:

f: func [a [number!]] [func [b [number!]] [a + b]]

g: f 1

h: f 2

>> g 1 
== 3

, this is much worse than error!

(1 + 1) surely isn't 3

I don't agree, because 'H is defined within context of 'G and uses 
'H binding.  its both consistent and logical... because Rebol binding 
is supposed to be static.

in the above example, I'd say the construct itself does what it should, 
but the real question is should one usually do this... no.  


I understand its a trap, but its not a trap for which the language 
is responsible, the user is simply leveraging the language.

you have two functions which share a parent context.

I do not need explanation, I can give it as well. The problem is 
not explanation, the problem is expectation.

ah... but expectation has nothing to do with implementation or logic. 
  expectation is *SOLELY* related to prior knowledge.   so this is 
not a question of what *it* should do  but of what *you* expect it 
should do.    :-)

Wrong addressee. I do not expect anything at all as I proved. What 
Pekr, Cyphre or other users expect is "real" to me, though.

Closure is my "child" in a sense. I wrote it because I found it is 
what people want to have.

(instead of "explanations")