World: r3wp

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

This is getting into lfunc territory, I think.

Yes, I was thinking I should study that

It appears that REBOL is just more free about this by default.  You 
make a context for a whole bunch of code, the words bind freely, 
and then you blow it all away on the context level.

The question is, how deep do you go looking for set-words ?

Yes, much more free. And I love it that way.

Well, again, I'll say... depends on what you're trying to write. 
 :)

True, large projects need rigorous standards.

I'm an EE, so my biases are going to be a certain way.  In fact, 
I try to bring that need for structure and formalism to things that 
are typically thought of as unimportant for having them, e.g. GUI 
code.

I'm all for formalism. Rebol allows many gradations from extremely 
free, to quite strict (if you're prepared to write some support functions 
like Ladislav).

I worry, for instance, about the semantics of if your app starts 
drawing on MOUSE_DOWN and then keeps processing MOUSE_MOVE as if 
you are drawing until you get a MOUSE_UP... but then your app loses 
focus while the mouse is down (for instance, due to a window popping 
up or maybe the user hit alt-tab).  So the app gets lost, or information 
gets lost, or whatever

Which is great for high-speed prototyping.

Yes, high-speed prototyping does seem to be REBOL's area.  I've tried 
Awk and PHP and Perl and such and thought they were all terrible.

Yes, that's very interesting, and I'm going to have to spend some 
more time thinking about it.

If you mean the mouse thing, I have a blog article / screencast about 
it

http://hostilefork.com/2007/11/25/lost-focus-placeholder/

Although I had noticed apps misbehaving on refocusing, I hadn't really 
thought much about it.

I guess my attitude was to just get the thing working first, and 
worry about these sorts of edge cases later.

That placeholder concept is cool. I wonder if it shouldn't be integrated 
into the OS ?

I like this quote: "Some facets of usability (
such as cancellation, 
undo, progress bars, and others) 
require software architecture support 
 .
Because they reach so deeply into the architecture of a system,
these 
facets must be built into the system from its inception 
rather than 
added after an initial system design
and user interface has been 
achieved."

Glad you like it... I just think it would be nice to see more things 
like that.  I don't know that I think this particular issue is super 
high priority, it just represents a more rigorous way of thinking 
about such problems.  My article on undo/redo tied to single user 
events is actually probably something I care more about, but it's 
another thing that people don't take as seriously as I... http://hostilefork.com/2007/11/25/undo-single-user-event/

No, it's excellent work. Advance the standard of modern applications.

Thanks again.  Well, I decided the best thing I could do was to show 
the ideas as I haven't really been writing software for a few years

It's all part of "The Great Plan" to clarify each concept in computing 
:)

Well, back to REBOL/Core :) I do feel that it's nice to find ways 
in which it can be applied more formally.  Maybe you can't validate 
the *process* by which a REBOL program achieves a result, but you 
can validate the *product* of its processes and check them for validity. 
 I think I would consider it that way, in that I would write tools 
to do all kinds of massive things in REBOL but then very carefully 
write an output-checker in another language.

Ok, gnite, and thank you for all your help.  I've updated the code 
and still appreciate suggestions: http://pastebin.com/m1f01d32a

Fork, it's tiny issues, but you might wanna do this:
In the set-value and switch functions, you have
... none = find ...
In the case of checking for none, you might wanna do:
if none? find ...

One of the really great things with REBOL, is that you can write 
stuff really short. Your get-value function is defined as:
get-value: function [] [] [v]
I would write:
get-value: does [v]

Parenthesis are good for readability, but you should know, that they're 
not necessary in many cases.
repeat index (length? cases) [
can be written:
repeat index length? cases [

Again it's a tiny issue, but it's good to know, if you wanna become 
a shark in REBOL coding.

It's good work, you've pulled! And a fine idea with an enum! type 
implemented as an object. A good way to get a feeling about context 
and functions in REBOL.

You talked about locals. If you have a function with locals and no 
parameters, you can also use HAS:
f: has [v] [v: 1 + 2]

sometimes you don't even need to check for none, as find returns 
none, if nothing is found:

if find ...

On parens, the reverse is true as well. Sometimes you need them in 
REBOL, where you wouldn't in other langs, because ops take precedence 
over funcs and math is strictly L->R.

As one who has been pushing for better PitL tools for REBOL, I hear 
you Fork. When I found REBOL, a lot of the initial things I did were 
to replace stuff from lanugages I was used to, that were "missing" 
in REBOL. There are still holes, and each of us will have different 
ones, but I eventually found that REBOL's way is not bad or wrong, 
just different. It takes a very different mindset to work effectively 
in REBOL. And use can use its power and flexibility to create a mess 
as easily (or more) as to create a beautiful and elegant solution.

For me, a breakthrough came not when I realized code was data and 
data was code, but (in my mind) that *everything* is data, and sometimes 
it gets evaluated. This can give rise to a view that things like 
mistyping "banana" aren't syntax errors, as you would view them in 
other langs, but "unexpected data". And if you think that way, in 
the enum case, how would you write code to deal with that. Not just 
at the local level of a /default handler for switch, but for propagating 
that information all the way up to the caller and user.

Another question I still struggle with is how forgiving and flexible 
to be. On the one hand, it's nice when you can accept a variety of 
input forms. On the other hand, where do you draw the line, and how 
to you write "soft" specs. At some point you still need to be able 
to make sense of the input and do the right thing with it.

Thanks Geomol!   I like these variations for function definitions 
(does, has, func) but the thing about the way I work is that I'm 
not particularly fond of having to change the structure of the program 
just because I've added a local or a parameter, or taken a local 
or parameter away.  To me the conceptual act of removing a parameter 
should be as simple as going to where the parameter is defined and 
deleting it, without having to worry about converting the container.

I did note a philosophical difference in REBOL where reducing the 
# of characters affects the performance characteristics... so using 
a shorter name for a variable or not using parens is going to be 
faster code by some measure... given my other biases, of course, 
I'd prefer anything that can help stop errors.

from your code : "l: none ; length of input (there's no length? on 
hash! I can find)". LENGTH? works on hash! values AFAIK .

Hi Gregg... yes it is a somewhat fundamental truism that code and 
data are one in the computer's own mind.  But separating this out 
and re-designing the computer to put them separate has shown benefit, 
even if it makes the model less simple.  For instance, chips where 
they actually have separate memory stores for code and data, which 
helps protect against things like buffer overflow exploits...!

Dockimbel: you seem to be right.  I wonder what happened when I tried 
it at first?

Just make sure Fork that when you work with series data and checking 
for length of the entire series that your at the head of the series. 
 You can do that by the following:

length? series: head series

That is especially important when working with list! datatype

Is it considered good practice to treat "none" as a false in a conditional 
expression?  I find that a little confusing, e.g. either find list 
value [truecondition] [falsecondition] ... what if "false" is an 
element in the list?

Hm, or for that matter, what if none is?