World: r3wp

i was just thinking again about the idea of IF (etc.) keeping a reference 
to the condition argument for you, that is, so that instead of writing:

    if x: select block value [do-something-with x]

you can write:

    if select block value [do-something-with it]


The reason people say it's not worth it is usually that of having 
to bind/copy the block - you don't want that in every IF call and 
probably not even in the ones where it would be useful (and, there's 
really no other name you could use for the function).

so, I thought, can we avoid the bind/copy in any way?


actually, i think we can. some people would run in horror maybe, 
and Brian will complain about it not being thread safe (we still 
have no threads though), but what about the native was changed to 
do something like:

    func [condition block /local it*] [
        set/any 'it* get/any 'it
        it: :condition
        also
            if :condition block
            set/any 'it get/any 'it*
    ]

i don't think there would be that much code to add in the actual 
native. the same thing could be done to other similar control functions.

I guess it could trip some users, otoh, we have many things that 
trip some users.

while thinking about that, i also thought that maybe UNLESS should 
return the "condition" value when it is "true". we use this all the 
time with ANY:

   x: any [select block value "default"]

maybe it would be more readable as:

    x: unless select block value ["default"]

just thinking out loud...

IT could be a function that returns the thread-local top of the stack 
of implied subject values. IF would then push a value on that stack, 
and pop the value off when it returns. Might be tricky to make error-throw-safe, 
but easy to make thread-safe :)

A *lot* of code uses the trick of having IF or UNLESS return none 
when the condition is not met, so your other suggestion is unlikely.

A *lot* ?
somewhat exaggerated :-)

More every day. Every time another developer learns about this (5+ 
year old) trick they start using it. It's even used in mezzanines.

It is mostly used in combination with ANY and ALL for control flow.

i use it too,but not so much

For complex control flow rules, i rather prefer CASE.

Most of the time, combitations of ALL ANY, can be replaced by a CASE 
structure (which is faster and more readable)

I prefer CASE too, and have rewritten many mezzanines to use it :)

It doesn't always apply to the task at hand though. The IF and UNLESS 
return values have been applied to the general R3 control flow model, 
as have the changes to the ordinal return values, map! behavior, 
...

Gabriele, it occurs to me that if IT was native it could look up 
the stack to get its value. I'll try writing a (security hole) REBOL 
version of the function later today - it would require debug privileges 
to run so that it can call the STACK function.

The advantage to this approach is that it would be error-throw-safe, 
as well as thread-safe, and require no changes to IF or UNLESS :)

R3-only of course.

The value returned by IT would not be evaluated, so that you can 
work with active values safely.

a sort of native POP function

No, it would have to search back. Simply popping wouldn't be enough. 
What I'm really interested in is seeing if I can add CASE support.

I don't know how the values evaluated are stacked by the VM. But 
i see the advantage of having a POP function.
We could easly create postfix functions.
e.g:
CONCAT: func [v][join pop v]

>> "a" concat "b"
=="ab"

All sort of new operators would be easy to construct

the stack function can return the prvious stacked value, but without 
removing it from the stack

I like Gabriele's idea.  I am one of those that has been using the 
if/unless return value for years, and quite often.

(those two sentences should have been two posts)

yeah, i didn't understood what u meant :-)

Gabriele had two ideas - I liked one of them: IT :)

Steeve, R3 evaluation doesn't work that way - it's not a stack machine.

Your Forth focus is showing :)

I have to admit I was also thinking about some simple stack capabilities 
few times :) (I came back to rebol from factor)

I have an old IF-IT function, which just does a bind/copy. I used 
it a bit when I first wrote it, but it hasn't become a part of my 
daily life.

Brian: a lot of code uses IF returning none, agreed, on UNLESS i'm 
not really sure, it's quite new. besides, it's not like R2 scripts 
run unchanged on R3; but anyway i was just thinking out loud, not 
really proposing anything.

Re: IT - the problem in looking up the stack is knowing which argument 
to look it up. I guess the first would work and be useful enough, 
though.

Isn't something like this code already built-in in REBOL and I'm 
just missing it:

copy-to: func [series [series!] arg /local cpd d][
    cpd: make type? series 10
    foreach item series [
        either not-equal? arg item [insert tail cpd item][break]
    ]
    cpd
]

array/initial?

no as that would just put the initial values in the series

This function returns a copy of everything until it finds the value 
specified and then it breaks.

Seems such usefulness that it would be built in - so I keep thinking 
I'm missing something.

you can do that with copy/part, as long as the /part is the same 
block

a: [b c d]
copy/part a find a 'd
== [b c]

Steeve, I love your thinking about the pop function.  I have wanted 
that feature before for operators myself.

it must be the same block, not just an identical one

yeah Henrik,  I'm suprised that we need to combine functions though 
to achieve that.

I guess that is my point.  I would think we simply would have one 
function that does that.

well, this allows you to put together any condition for the item 
you want to stop at, so I think it's OK. it's something else, if 
the code pattern occurs very often (never used this one).

Yeah that is fine Henrik.

wha tis the suffix-map in REBOL used for?

Brian, even if the Rebol's VM  is not a true stack machine. It has 
a data stack, so that, the POP function could be emulated in some 
way.

A forth kernel, is nothing else than that. To simulate a stack machine 
on a processor that is not designed that way initially.
However, your response suggests that the cost would be high.

If it was possible, the 'IT function could be emulated like this:

IT: does [push pop]   ; pop the and repush the last stacked value 
(just to read it without modifying the stack).

With R3, currently we can do...

>> it: does [first stack/args 2]
>> if 1 + 1 [print it]
2