World: r3wp

http://pastebin.com/m20abc2ca

Ok, that explains the enum object well. However, it looks like a 
waste of time to me ! (sorry) but I haven't felt I needed this in 
rebol for many years !

I suppose it depends on what kind of code you write

This specific case came up when I tried to install a large, professional 
grade REBOL system written by people who are as I understand it very 
good at REBOL

That may be true.

There is no integrated debugger, and so tracking this kind of stuff 
down isn't as easy as it might otherwise be

Can we see what the specifics of the original case are with respect 
to the enum ?

nextstep: cgi 'nextstep

So it was getting a CGI variable in an HTTP post

Then it did switch/default nextstep [ (various cases, pages long) 
] [ the default case ]

A bug in the cgi system left a trailing newline on the nextstep variable

SO instead of being "apache1" it was "apache1^"

Ok, so you saw the enum object as an extra level of protection against 
this kind of bug.

To more strictly validate input.

Or was it just to catch where the bug was ?

It validates on all sides, it protects against programmer error in 
the usage as well as things like this where the data source or function 
has a problem.

I do like REBOL from what I've seen so far!  But I saw somewhere 
that it was being compared to modeling clay... it's a paradigm shift 
for people who are used to systems that do a lot of global analysis 
of your program before it runs the first line of code to catch basic 
errors.

Yes, definitely.

make-enum-type should define 'ret local.

I do remember that, though I don't exactly remember what happens 
if you don't do it

It sets 'ret global. Check this by running the script then probe 
ret in the console.

Ah, ok

So same for test-block

(start/end)

And pretty much everything else... I'll go over it.  I should probably 
use "function" as I don't care so much for /local

Yes, but that's just your test code. Usually I don't bother being 
so strict with test code because I know I'm going to throw away the 
console afterwards. The reusable library part is the important part 
to be watertight.

I get the feeling that I'm going to want to have an analysis tool 
which will read through the functions, find any variable: assignments, 
and ensure they're in the local list unless there's some sort of 
indication they should be global.  Because it seems relatively uncommon 
that I would, inside a function, set things in the global space. 
 I'd be happy to use something wordier (set?) for that

I recommend FUNC over FUNCTION because having "/local" written makes 
it clearer and explicit what the locals are, and is shorter when 
there are no locals. Compare:

When there are no locals, func wins, because less characters to type.
	func []
	function [][]

When there are locals, same number of characters written, but func 
more clearly specifies the locals.
	func [/local]
	function [][]

Additionally, when you are modifying your func spec back and forth 
so that there is a need, or no longer a need, for locals, then func 
wins by less typing needed.

Hm, well, it's not a tremendous deal but I feel like always being 
forced to remember typing in that second group would remind me that 
I need to think about what goes in it

Is there a way to set things locally in a do block?

Or do you have to do a nameless function to get a local context?

e.g. do func[/local v] [v: 1+2]

I go without such a tool for analysing function local variable consistency, 
which, I think, turns out to be a difficult problem to solve. Some 
people have written alternative function creators which somehow make 
set-words into locals by default (Ladislav ? with his lfunc ?) or 
something like that. I just maintain a strict habit of checking for 
accidental globals. It's good to review your use of variables regularly 
anyway, and be aware of what context they're bound to.

use [v][v: 1 + 2]

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