World: r3wp

In other cases where you want ot break out of the inner loop, just 
return an empty block:

>> z: func [] [return []]
>> forever [do z]        
(escape)

Graham, catch and throw

hehe .. that's what I said

ah... yes

Continuing from Puzzle Answers. Isn't this a bit funny or strange?

First some failed attempts to make 2 a word of value 1:

>> 2: 1
** Syntax Error: Invalid time -- 2:
>> set '2 1
** Syntax Error: Invalid word-lit -- '2
>> set [2] 1 
** Script Error: Invalid argument: 2


So 2 shouldn't be a word. But then it's possible anyway with this 
trick:

>> set to-word "2" 1
== 1

2 is still a number:

>> 2
== 2

But 2 as a word exists:

>> get to-word "2"
== 1


I think, it's a bit strange. If it's intentional or not, I don't 
know.

the first behaviour (the error) would be the expected behaviour if 
you assume that base symbols such as number are protected from modification 
- this protection in R2 at least is not complete.

consider trying to audit code with blocks made in word form.. another 
source of insecurity / bugs

The only thing that blocks numbers to become word! values is the 
lexical scanner. When you type anything in console (or DO a file 
script), your input is first a string! value that gets LOADed (that's 
where the lexical scanner raises errors). TO-WORD allows to bypass 
the LOAD phase and force the conversion of any symbol to word! value.

Maybe it would be a good idea, if constructors like TO-WORD etc. 
would do a lexical scanning of the result?

Anyway, this gives us a probably unique method for strong code obfuscation. 
:-)

heh indeed!

heh, yeah! It's fun at times, but is it really a good idea?

the set to-word "2 + 2" with spaces is a bit of a worry

I agree, TO-WORD should enforce word! syntax rules on argument and 
raise syntax errors accordingly. That would be a more logical behavior. 
Maybe Carl had some design issues to workaround by allowing this 
(or maybe it's just an implementation flaw).

>> set to-word " " "secret"
== "secret"
>> blk: reduce [to-word " "]
== [ ]
>> reduce blk
== ["secret"]

Good one! Nothing can be something in REBOL. :-)

There is no spoon
 or "The truth is elsewhere" could make nice REBOL baselines. ;-)

R3 however does do a whitespace check thankfully

whitespace characters appear invalid in words in R3 - although if 
they are able to be redefined that could be an issue/weakness

Geomol <funny or strange>

It gets odder ( or less consistent) as '+ does seem to be given special 
handing......

What I really wanted to do to solve the puzzle was:
    -- set to-word "2" 5
    -- set to-word "+" none
The block then becomes (in effect)
   do [5 none 5]
   == 5
      

But DOing the gimmicked block in R2 fell found of '+ being both a 
native and some hardwired syntax in the interpreter:

    set to-word "2" 5
    set to-word "+" none
    blk: copy []
    blk: reduce [to-word "2" to-word "+" to-word "2"]
    probe blk
        == [2 + 2]
    do blk
        ** Script Error: Invalid operator: +
        ** Near: 2 + 2

In R2 the operators are special-cased by DO. In R3 they handle themselves 
(quicker that way).

Wouldn't it be nice to do:

series: [1 2 3 4 5 6 7 8 9 10]

find series > 5

such that it returns:

[6 7 8 9 10]

Even extend that to use CHAR values also.

I agree that adding a refinement to include a compare func would 
be pretty usefull!

maybe some other func provides this and we're not thinking about 
it.

Seem I'm always wanting this functionality and would be a very useful 
upgrade.

Could be Maxim, I often put something down - only to find Gabriele 
or Ladislav showing me another way.

there is something like filter function I think (or you can make 
one that takes values and expression)

I know we can easily build a function to do this but it seems so 
well suited to the 'find function.

find/match series (6 =  pick serie 1)

would make a lot of sense to me.

In R3:
 
remove-each x series [x <= 5]

We ave remove-each in R2 also but that is a bit different as it is 
doing removal - I don't want something removed just a subset returned.

I submitted my request to cure-code.

yess remove actuall modifies the series being given, find just changes 
its offest.

it would be more like extract with a /find index.

You could copy the series first, although obviously this impacts 
performance.

http://curecode.org/rebol3/ticket.rsp?id=781

have we had a discussion about a variable /skip based on FIND? I 
think it's a good idea in general.

not sure.

I think its a good idea to ahve find like that (so that it gives 
subset) but expression would have to be a block so you can put any 
code inthere and things are systematic

but even extract creates a new series, we just want to change the 
offset, its much more efficient in all cases... and yess I would 
have used that VERY often.

I think everyone would use it very often.  I can't believe we haven't 
created it yet.

basically its exactly like sort's /compare argument.

like /skip, maybe the /compare refinement could become more generalized. 
 this would be a logical complement to the flat record concept which 
/skip enables... 


wrt SQL, in some cases /compare is used as a where clause, other 
times its the argument to TOP, somethimes its used as the ORDER-BY, 
its very symmetric and much simpler to have the same refinement for 
all of these IMHO

Would be nice to add that functionality to those other functions 
that could use it.

So the desired feature is to return the series at the position of 
the first element which meets a specified condition?

yes.

since find already has /reverse that would be nice to have it use 
that as well such as:

find/reverse series > 3

there some details to consider for string parsing though...