World: r3wp

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

>> if ( reduce first find [false true] 'false ) [print "false is 
in the list"]
false is in the list

I'm looking for how to make first find [false true] 'false NOT print 
false is in the list

As per my usual question method, if y is ( reduce first find [false 
true] 'false )... what is f(y) to make that happen :)

because FALSE there is a word!, not  logic!.

>> first find [false true] 'false
== false
>> type? reduce first find [false true] 'false
== word!

That much I get, I just thought that reduce turned false-as-word 
into false-as-logic and it does not

Yes, it's still a word! and not a logic!, even if you reduce it.

So what turns it into a logic, if not reduce?

do

reduce the block instead

>> if ( do first find [false true] 'false ) [print "false is in the 
list"]
== none

looks like R3 does not exhibit that behavior. it's reduced to logic!

Ok, great, that's the case I was worried about then...