World: r3wp

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?

None! is not the same as false

Here is would be the difference Fork:
>> found? false
== true
>> found? none
== false

Ah, I see find returns a series, not a word.  Got it.

yes

I'm trying to wrap my head around the situation I'm concerned about 
but don't know quite how to say it, but it's something like: if [first 
find [false true] 'false] [print "False is the first element"]

>> if first find [false true] 'false [print "false is the first element"]
false is the first element

>> probe 1 = 0
false
== false
>> probe first find [false true] 'false
false
== false

>> pick [true "false is the element"] false
== "false is the element"

>> type? probe 1 = 0
false
== logic!
>> type?  probe first find [false true] 'false
false
== word!

Fork the false is being returned because it is the last value.

>> (1 = 0) = (first find [false true] 'false)
== false

in [false true], both are word! values, not logic!. If you want logic! 
values : logic! = first find reduce [false true] false

>> (1 = 0) = (first find reduce [false true] false)
== true

A ha

Is there a version of probe that prints the type also?

Not by default, but here's one : probe*: func [value][probe :value 
probe type? :value :value]

Dockimbel: very useful!

>> if 'hedgehog [print "hedgehog"]
hedgehog

Oh my.  Well, I think I'd rather define a "safe" if that only accepts 
true/false if there isn't such a thing

In REBOL everything is TRUE except false and none! values.

Btw, " favorite_fruit/set-value 'banana " doesn't look very rebolish 
to me...IMHO, REBOL way would be more like : " set-enum favorite_fruit 
'banana ". When you MAKE an object! in REBOL, all its functions are 
duplicated, so keeping the functions inside an object! and using 
it as in a class/instances model ends up eating a lot of memory. 
That's why the more "rebolish" way, where the code is out of the 
objects, is the way to go if you deal with a lot of instances (which 
might be the case for a "class" like enum!).  Remember that REBOL 
objects are prototype-based, meaning that they are created by cloning, 
not by instantiating a class. R3 will maybe bring us true class! 
datatype or at least a clean way to implement it by ourselves.

To check, if false is the first element:


>> if head? find [false true] 'false [print "false is the first element"]
false is the first element

>> if head? find [true false] 'false [print "false is the first element"]
== none

Geomol: good point... that wasn't what I was doing, the quote should 
have been "false is in the list"  :)

Dockimbel: That's quite good to know, thank you, I will make that 
change.

It was a quick ping-pong up there, so I'm not sure, if you know the 
answer, but to find false in a series:

>> if find [false true] 'false [print "false is in the list"]
false is in the list

And you know, this isn't the value FALSE, it's just words.

To check for the logic! value FALSE, you have to reduce the block:


>> if find reduce [false true] false [print "The logic! value false 
is in the series"]
The logic! value false is in the series

>> if find reduce ['false true] false [print "The logic! value false 
is in the series"]
== none