World: r3wp

later

Later, thank you...

Fork: always using "quoting" is actually the source of your problem, 
as it does not really bring symmetry in. the reason is that ' is 
not an operator, rather, we have word! and lit-word! as two separate 
types.

it is true that you have to know where evaluation happens and where 
it does not. but this is the key of rebol: since data is code and 
code is data, there is no explicit sign of what can be evaluated 
and what cannot. anything can be evaluated, if you make the interpreter 
evaluate it.

so you have to decide whether you are getting something to be evaluated 
or not.

about "word-active" values: i'm not sure lit-word! being word-active 
is useful, but i'm sure Carl has a good reason for that. it's a good 
thing to always use :x instead of x when you want to get the value 
as opposed to evaluate the word (they are the same in most cases 
except a few types, especially any-function! types and, as you have 
seen, lit-word!)

Thanks Gabriele, I think I understand, and knowing the actual answer 
is helpful in understanding the fundamental springs and pulleys that 
make the REBOL machine work.

One of the first errors I encountered while trying to run an installer 
that was built in REBOL was that a state machine driven by a variable 
was failing to match a case and falling through to a default, due 
to a spurious linefeed on one of the cases that was read in.  It 
was attempting to match foo, but had foo^/ ... and so it fell through 
to the wrong case.  So I have been tinkering with a checked enum 
for REBOL.

If anyone has input on to the approach, I'd appreciate feedback: 
http://pastebin.com/d698d3c16

Oops, deleted some spurious code and that made a typo, will make 
a better version that prints section headers for the tests...

I guess you figured it out already, but you can use TRIM to remove 
leading and trailing whitespace from your input.

I'm not sure why you are taking this approach, but it seems to be 
something which you might implement to make another language more 
useful :) I don't think it's needed in rebol. Perhaps you could explain 
how you're using this enum/switch in more detail...

A small tip:
	for index 1 (length? cases) 1 [
is usually better as:
	repeat index length? cases [

(I almost never use FOR. I use REPEAT very often).

Fork, perhaps you can show us the original (approximate) example 
from your installer state machine, with a few example inputs and 
expected results. Then we can see what started all this :)

Here is a better documented version:

http://pastebin.com/m2e06f2b7

I explain the cases in the header

Here is the output with performance data of the testing:

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?