World: r3wp

Ah, an lfunc, that sounds nice

do [
	use [v][v: 1 + 2]
]

context [
	v: 1 + 2
	print v
]

same as
make object! [
	v: 1 + 2
	print v
]

I see... context looks like a good thing, great!

Yes, very useful.

?? context

When I do something like a for loop and I specify a name for the 
loop variable, is that defined globally by default or locally?

which reminds me; make-enum-type can be optimized like so:

make-enum-type: func [ possibilities [block!] ] [
	make enum! [
		p: to-hash possibilities
		l: length? possibilities
	]
]

so no need for a local at all.

Loop functions set words local, in a temporary context. You can test 
whether loop functions set words global or not quite easily:

>> for i 1 10 1 []
>> i
** Script Error: i has no value
** Near: iÂ

Yes, thanks for reminding me of the at-hand-interpret-as-you-type 
thing :)

All I can say is, enjoy...

Is there a way to get the native-switch that is better than how I've 
done it?

(But I was thinking, the above doesn't prove that  i  is not set 
global during the loop, then unset at the end, but you wouldn't expect 
that sort of sneaky behaviour...:)

Yes, you've set 'native-switch global. It appears to be used only 
in the enum/switch function.

You could simply refer to system/words/switch instead. No extra variable 
necessary here.

A-ha... nice.  Now here's something... can I make it so that my test-block 
runs the code in its body in a local context?

I guess, use [][do :block] ?

No, that use would be no different than just
	do :block

Because, by not specifying any use locals, you are making a context 
without any local words in it.

(ah... except 'self, but that's not important here)

Better than
	loop times [do :block]
is
	loop times block

Now that one I got from a sample on the web.  :)  http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=timeblk.r

Which also didn't declare start: locally...

The words in block maintain their bindings. This is what you want; 
the words retain the meanings from the context the user wrote them 
in. (ie. your locals do not affect those words because nowhere do 
you bind the words to any of your own contexts.)

do context[do :block] ... that would give it a new context and run 
it there.  What kind of thing would that break?

So if I write
	test-block "section" [ print reps ]


then REPS means what *I* (the user of the test-block function) thinks 
it means, not what test-block thinks in its little context.

Hmmm.  Ok, so if I want to have local variables in a test-block the 
context declaration would need to live there?  That is different?

(First DO does nothing extra, just returns the object)
Again, 
	context [do :block]
is no more (except 'self) than:
	do :block

I did try that but it didn't seem to evaluate the block

You could do something like this:
	use [var1 var2] block
or
	context join [var1: 100 var2: 200] block

Now it's evaluating, hm.  Wonder what I did before.

There're lots of confusions here when starting out :) beware !

Yes!

But I'm wondering why you want to subvert the meaning of the words 
in the block to your local meanings.

Well, I have one test block after another in a line

Surely you want the block to retain all its meanings ?

I'm used to C++, so I like scopes.  They make me happy :)

So I was wondering if I could let the concept of each test-block 
being a scope come from test-block itself

Rebol's contexts are better ! (But scope is good for compiling.)

Because if one test block goes:

var: 15

I don't want the next test-block to be entered with var set to 15

I want it set to none initially

Oh ok, so letting set-words be locals automatically.
	context block

Does context affect anything besides set-words ?

e.g. will everything else bind the same as you would have otherwise 
expected?

No, and the set-words are searched only in the block specified (not 
"sub-blocks").