World: r3wp

I think we can.  One that can probably accomodate much more.

I would want to put all values that are going to be tested in a block.

a < [1 2 3 4]

Would be nice if we use op! values as an argument to functions.

yeah that is what I initially wanted to do Henrik.

I remember from my HP48 calculator that any numbers put in a block, 
could be operated on like that. But I think this is the beginnings 
of vector operations, which is a big area that should be done right.

My function is actually very restricted in that it looks for the 
op! as the second to last value and the comparator as the last item.

because I would also like to see:

>> 1 + [2 3 4 5]
== [3 4 5 6]

in R3 there are ways to do this with a bit more code.

I could make that change to my function and easily accomodate that.

No outside of a single block though.

I would love to see it in R3, but so far nothing from Carl WRT this 
particular feature. I think it might complicate op! way too much.

I'm sure we can do something in the mezz sense once R3 gets released.

Shouldn't < > and = return as a logic values as well as being op 
values?

>> logic? get to-word "<"
== false
>>

I guess because it doesn't return true or false until it operates 
on something it wont return a logic value.  But maybe we should at 
least subclassify some operators to distingish them more.

some modifications made:

op+: func [blk /local op args arg blk2 blk3][
    op: first back back tail blk
    blk3: copy []
    arg: last blk
    if word? :arg [arg: get :arg]
    args: copy/part blk find blk op
    blk2: reduce [op arg]
    foreach item args [
        insert blk2 item
        if item: attempt [do blk2][

            either find form blk charset "<>=" [return item][append blk3 item] 
              
        ]
        remove blk2
    ]
    if not empty? blk3 [return blk3]
    false
]

>> op+ [1 2 3 4 + 1]
== [2 3 4 5]

what you return is that the datatype is op!, not logic!, so logic? 
returns false.

>> op+ [1 2 3 4 > 2]
== true

yeah I know I thought it would return logic and op depending on the 
test.

would be nice to have lop?

lop? - returns true or false if operator returns logic values.

what do you mean?

ok

lop? would be a function

well, you wouldn't know without running actual tests with the operator.

yeah you can

just like I do in the function above that I wrote.

please explain, because I can't see where you do that. :-)

I'm just checking the charset

all the ones that return logic are those operators that are or have 
in their form the characters "<" ">" or "="

lop?: func ['op][if find form op charset "<>=" [return true] false]

>> lop? +
== false
>> lop? <
== true

I see.

seems handy to me.

could be modified to become a true mezz

;a bit revised:

lop?: func ['op][if all [op? get op find form op charset "<>="] [return 
true] false]

You can sort of trick your way around things with ops in most cases. 
e.g.

	>> fn: func ['op a b] [op: get op  op a b]
	>> fn < 1 2
	== true


But I avoid doing that. It ends up not being worth it, IMO, when 
you start to reuse things, generate code, etc. Just use func alternatives.

heh but cool Gregg.

; Here's a thought:

	any-where: func [series [block!] test [block!]][
		foreach value series compose [if (test) [break/return value]]
	]

	probe any-where [1 2 3 4][value > 4]
	probe any-where [1 2 3 4][value >= 4]
	probe any-where [1 2 3 4][value < 4]


; I know it's a two block solution, but it's pretty language friendly. 
 You can recycle tests too:

	test: [value > 4]
	probe [1 2 3 4] :test
	probe [5 6 7 8] :test

Oops, forgot the function at the end there...

Very nice Chris!

It's kind of like an "apply-any".

simple problem:

>> a: [1 2 3 4 5]
== [1 2 3 4 5]
>> b: at a 3
== [3 4 5]
>> a
== [1 2 3 4 5]
>> b
== [3 4 5]
>> remove a
== [2 3 4 5]
>> b

== [4 5] ; I wonder if it's possible to make the index "sticky" at 
[3 4 5] in a relatively simple way. If it were, that would be very 
cool.

copy it first!  :)

nope, it has to be the same series

and if you copy the index? as well?

it must be the same series

Unless this is a feature request, you'll need an alternative to remove...