World: r3wp

paul, for example a BREAK inside the cases block will break the WHILE 
inside SWITCH, not the loop the user probably intended.

ladislav: since <]> is not a valid tag in html, i'd say that could 
safely be considered a block close bracket.

i.e. if we make tag parsing more strict, we can probably solve the 
problem.

Maybe then if we just add all the valid cases that meet the criteria 
to a block during the while loop and then evaluate each item in the 
while loop is completed?

after the while loop is completed rather.

that's what my switch does :)

hehe

sounds good to me

Ahh I see where yours might have a problem also

Max, WRT FILL, I have similar funcs, and I agree that we need something 
like this. I tried FILL and PAD as names, but didn't like them as 
much as JUSTIFY. JUSTIFY is longer, but IMO it removes the ambiguity 
for /left and /right.

Rather than pushing for R3 inclusion, we should try to get revault 
up, and put things there. :-)

Here is my new switch:

switch: func [
    "Finds a choice and evaluates what follows it."
    [throw]
    value "Value to search for."
    cases [block!] "Block of cases to search."
    /default case "Default case if no others are found."
    /multi "evaluates what follows all matching choices"
][
    cases: find cases value
    if multi [
        multi: copy []
        while [all [not none? cases not tail? next cases]][
            if not none? cases [
                append multi first cases: find cases block! 
                cases: find cases value
            ]
        ] 
    ]
    either not none? multi [
        if not empty? multi [do multi]
    ][

        either cases [do first find cases block!][either default [do case][none]]
    ]
]

Small end tweak, instead of [either default [do case][none]] just 
[do case] -- if the there is no default, the result will still be 
none.

true - I see another problem also thought which is when multi and 
default are used together so I need to fix that also

see if this is any better:

switch: func [
    "Finds a choice and evaluates what follows it."
    [throw]
    value "Value to search for."
    cases [block!] "Block of cases to search."
    /default case "Default case if no others are found."
    /multi "evaluates what follows all matching choices"
][
    cases: find cases value
    either multi [
        multi: copy []
        while [all [not none? cases not tail? next cases]][
            if not none? cases [
                append multi first cases: find cases block! 
                cases: find cases value
            ]
        ] 
        either not empty? multi [do multi][if default [do case]]
    ][

        either cases [do first find cases block!][if default [do case]] 
    ]
]

With some help from Carl, I got to this:

switch: func [
    "Selects a choice and evaluates the block that follows it."
    [ throw ]
    value "Value to search for."
    cases [block!] "Block of cases to search."
    /default case "Default case if no others are found."
    /all "Evaluate all matches (not just first one)."

    /local code found?
][
    code: clear [ ]
    while [cases: find cases value] [
        either cases: find next cases block! [
            found?: yes
            append code first cases
            cases: next cases
            unless all [break]
        ] [break]
    ]
    do either found? [code] [case]
]

two local words, but shorter. also, it turns out that using a path 
for system/words/all is slower than using the either inside the while.

thats cool Gabriele.  Nice and concise

I had this (how many ways to skin a cat?):

switch: func [val cases /all /default case][
    all: if all [make block! []] 
    while [cases: find/tail cases val] [
        either cases: find cases block! [
            either all [
                case: append all first cases
            ][
                case: first cases
                break
            ]
        ][break]
    ]
    do case
]

I like Carl's code - I can't remember the last time I used the 'unless 
function.

or your code Gabriele - or both

Ok I looked at the performance from a trace perspective of three 
switch implementations - mine, Gabriels and Chris's.  Out of all 
of them mine was least efficient, while Chris's was the most efficient. 
 So if all of them do what is needed then I would say go with Chris's 
implementation.

what if append was replaced with insert tail? that would make it 
a tiny bit faster

Yes I would think so Henrik

Don't forget that 'append will be made native.  Also is it faster 
yet to change the first line to -- all: if all [clear []] -- as with 
Gabriele's function?

I can check

Yep barely faster

When I say faster I mean in less trace output

paul, that's a good idea, using trace to do that. wonder if that 
could be wrapped into a counting function that counts the amount 
of trace output?

I do it all the time to optimize my scripts these days

trace is native. I vote for adding something to trace to make stats 
from the output, perhaps just a single integer that shows how many 
functions were run through.

I hardly ever use it because I think it provides too much output

yeah but it gives you a good idea of what is going on.

especially the resulting values

is it possible to store trace output?

sure

you can use echo or copy from the console

hmm.... a bit inflexible, I think. It would be nice to bypass console 
output, and store the output in memory for later scrutiny. this would 
avoid needing to popup a console to an end user.

just echo the information

before you turn on trace just do this:

echo %trace.txt

still outputs to console. I'd like to avoid that.

oh I see

I never tried it - or had need to without console output

well, I'm not sure how useful trace is to me anyway.

chris, that is nice too.

about trace, if you need a count you can probably just use the STATS 
function.