World: r3wp

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

IT would need to search up the stack to find the nearest appropriate 
function call frame - it doesn't just apply to the next call up.

Gabriele, UNLESS has been around for many years - just not used by 
many people because of personal preference. They used the slower 
IF NOT instead.

Paul, you won't need stack tricks to get user-defined operators in 
R3 - we'll just use user-defined op! functions.

The reason Steeve's proposal doesn't work is because the result of 
the prior expression is thrown away, not pushed on a stack.

Oh, and suffix-map is used by the codec system, afaik.

Brian, Steeve's examp;e works, you just have to do >>secure none

Sorry Bolek, I should have been more specific. I meant Steeve's POP 
proposal and the CONCAT example wouldn't work (for reason's stated 
above). Gabriele's IT proposal and Steeve's sample implementation 
of it would work a little, but would need modification.

Brian, how many scripts on rebol.org use the result of UNLESS?

There are 45 scripts on FREBOL.org that appear to use UNLESS (there 
may be a few false positives in this -- if, say, the word UNLESS 
has been reused):
   http://www.rebol.org/search.r?find=unless+[b]

and, how many of them do something like:   var: unless ...

I was reading http://www.chalicegames.com/swym/SwymWebIntro.html
and some concepts were interesting to me(especially ETC), so I made 
REBOL equivalents:

http://box.lebeda.ws/~rebolek/rebol/swyv.r


There's a documentation in the script, so just few examples of what 
it can do:

SERIE:


>> serie [etc 1 2 4 .. 20 cycle [1 2 3] length 5 iterate [x: x + 
10] from 10 5]

== [1 2 4 8 16 1 2 3 1 2 10 20 30 40 50]

COMPARE:

a: [1 2 3 4 5 6 7 8 9]
b: [2 4 6]
>> compare a b [some a > every b]

== true


>> compare a b [one a > every b] 

== false

FILTER:

>> filter serie [iterate [x: x + 1] 10 ] [[x > 2] [x < 5]]

== [3 4]

>> filter etc [3 6 9] 100 [x > 250]

== [252 255 258 261 264 267 270 273 276 279 282 285 288 291 294 297 
300]

>> filter serie [1 .. 10] [[x > 5][zero? x // 2]]
== [6 8 10]


It's written in R3 but should also work in R2 (not tested). It's 
not optimized so if you're interested in it, feel free to do whatever 
you want to improve it (more patterns that ETC can recognize...).

Cool Bolek.