World: r3wp

How I came about this is that I was writing a REBOL script that would 
dump out a file of function definitions for all the builtins.  I 
made some symbol browsing rules for a code editor that would pick 
up on function and variable definitions and let me jump around the 
code easily.  So I was using a lot of function names very literally, 
and in fact, as conditions of switch statements.  e.g. switch commandname 
[usage [print "Usage"]]

The switch statement wasn't the source of the problem... others were. 
 I became interested in making all "quote-like" contexts use the 
quote escape, for code consistency.

(Rather than being so sensitive to the details of whether contexts 
were evaluative or not, and using non-quoted style only if it wasn't)

I knew I could go commandname: 'usage and then later switch commandname 
[usage [print "Usage"]]. But  I was looking for a symmetry and was 
working on quoteswitch commandname ['usage [print "Usage"]] .  I 
could not figure out how to write quoteswitch without the above ability.

Note: f(y) that I sought seems to work as " to-lit-word to-string 
y", hence z is superfluous.  I'm still wondering if there's a better 
f(y)...

I know it seems silly, but
    to-lit-word 'x
will do. You don't need the to-string.

Your f is to-lit-word.

All you have to remember is that word! and lit-word! are different 
datatypes, so values of those different datatypes won't be equal.

You are looking for symmetry, but you are not being symmetric in 
evaluation. If you really want symmetry, REDUCE the switch block 
before you pass it to SWITCH.

Ah, well that's even better.  :)  So the trick here, though, is you 
can't do z: to-lit-word y, and then switch on z.  If you do that 
you have to switch on :z -- I think this is what confused me.

No, you can switch on z.

It doesn't work for me

e.g. if z is a lit-word of value 'x  ... then ? z says just x ... 
but :z says 'x

When evaluate a z that is assigned a lit-word! value, it will return 
the lit-word! value. If you evaluate 'z, which is a lit-word! literal 
value, it would return z, the word value.

Er, I meant just a reference to z and not ? z, sorry.

(Quick question, I'm new to altme... how do I type in a multiple 
lines without submitting the message?)

OK, I guess you're right (just tested). Lit-words seem to be "word-active" 
in R2. I'll check R3 as well.

(click the pencil button, 5th from the left. then do ctrl-s to send)

(Ah, thank you.)

Same in R3. I'll have to do some code review on the mezzanines to 
check for code that expects the opposite.

I wonder if  this is a bug or a feature?  e.g. is there a fundamental 
part of REBOL depending on this behavior in order to make certain 
evaluations work...

I already did a review for other word-active values in a lot of the 
mezzanines. I just have to check for lit-word! values too. Fortunately 
lit-word! values assigned to variables are _really_ rare. Most people 
use word! values, just using lit-words literally.

That feature you mention is the word-active feature. It's also what 
causes functions to be evaluated. It's sort of like putting a function 
reference in the first position of the list in Scheme rather than 
the other positions.

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