World: r3wp

proably just much faster.

Yeah that is the only thing that I can think of.

paul, the new switch allows multiple cases, thus /all makes sense. 
actually, I was able to use that in the imap protocol, which was 
using a "trick" to obtain the same results. so, now it's more readable 
and more elegant.

Max: the trouble with the 'c variant is, that REBOL does not offer 
corresponding FIND

I don't think using /all is a good idea for any function though. 
 I recall having a problem once where it seemed that I killed the 
global all function by using that.

at least when passed to the function in a block that was being evaluated.

This kinda something like your looking for:

multi-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"
][
    either multi [
        while [all [not none? cases not tail? next cases]][
            cases: find cases value 
            either not none? cases [ 
                do first cases: at cases 2
            ][
                either default [do case][none]  
            ]
        ]     
    ][
        either value: select cases value [do value][
            either default [do case][none]
        ]
    ]
]

ladislav, I understand that in the current version there is no native 
way to find the first value of integer! (not an integer! type value 
but the datatype value itself)  maybe that could be added to 2.7 
as a refinement.  its a valid request, especially since we are considering 
and openly commiting to updating the switch .   no?

Actually, my multi-switch needs a couple more tweaks

Gabriele, did you try it ? All my tests til now are with integers 
!  I think you didn't notice that when value is an integer I am changing
	TO END
to
	TO integer!   ; (not the value itself)

(This just proves again that this parse-based version is confusing...)

paul, your version would not work as you intend in some cases. about 
/multi vs /all, the "all" is a standard, used by CASE too; it does 
not create any problems with the global all in the cases block.

Anton, so let me try that...

1 1 value    will not work if value is a word!, which is common with 
switch.

Ah yes, you are right. Parse tries to evaluate the word. Hmm... Looking 
worse and worse...

I suppose I could convert words to lit-words, but then I will have 
to continue on to also make a custom rule to parse lit-words, which 
are more difficult.

what do you think about: load "[<]>]"

Interesting. Looks correct to me. The block begins, then the tag 
(a type of string) begins which can contain any character just like 
strings, then the tag finishes with the >

unfortunately, this disallows load "[<]" to work

so tags are really parsed?

I always thought being able to load tags within scripts was a risky 
business... there is no lexical differenciation from the operators, 
its the same problem as with html itself.

IMHO blocks must be the clear winner in lexical analysis whenever 
there is an ambiguity.

rebol is the boss here, not html.  and if this means escaping block 
chars in other datatypes, well I think it should be done.

I'm not saying tags should not be able to contain any string like 
they do now, but maybe, they should be extended to support escaping 
like strings, which can handle   {}}  when the inner } is escaped.

hmm, maybe we should first look for the first occurance of "] ", 
with space involved, as only this case means end of the block, no? 
:-)

Ladislav, yes, it's just like:  load "[{]"

hmm, what a nonsense I wrote :-) end of block can't be determined 
in such a simplistic way :-)

What do you mean Gabriele - what kinda of scenarios do you believe 
that multi-switch wont  in?  Maybe I can fix it for those.

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?):