World: r3wp

There may be better ways:
   first do to-path reduce ['a get 'd get 'e]

thanks

>> a/:d/:e/1
== 1

more things to try :)

Great .. works

is there a quick way to determine whether a string is enbased without 
debasing it?

Well, enbase.base 2 is easy:
     string: enbase/base "cffdf" 2
     "01" = sort unique join "10" string
And that is easily extendable to the other bases

But you might get some false positives -- say a base 16 number happened 
to be all 0s and 1s.

I think that might be OK. It's just that I need to process some fairly 
large strings 50-100 kb each and it should really happen in near 
real-time, if possible.

Good luck!

For raw speed, experiment with dropping the SORT -- and try DIFFERENCE 
- it may be faster for large strings.
    "" = difference "01"  join "10" string

Curiously, this works in R2:
    x: charset ["0" "1"]

    find x string     ;; returns TRUE for all strings made up of just 
    "0"s and/or "1"s

It does not work in R3 -- which may be deliberate and sensible.

Don't worry, I added another comment that deals with the terminological 
problem :)

You were focusing on localiity of where the code was written, and 
I was talking of locality in the code that the flow of execution 
goes through at runtime. For instance, #1744 makes it difficult for 
non-local-definition code to do man-in-the-middle attacks or spoofing, 
making it useful for secure mezzanine control flow functions. But 
#1518 prevents you from being able to pass THROW/name through unknown 
code at all, making it useless for making mezzanine control flow 
functions at all. Fixing #1518 is what we do to make #1743 possible, 
and once #1520 is implemented then the arms race will be over, everything 
else could be mezzanine or user-defined.

Henrik, i suspect that debasing may be faster than checking eg. with 
parse. are we talking base64 here or just base 2 and 16?

base64

given: http://en.wikipedia.org/wiki/Base64

>> base64: charset [#"A" - #"Z" #"a" - #"z" #"0" - #"9" #"+" #"/"]
== make bitset! #{
000000000088FF03FEFFFF07FEFFFF0700000000000000000000000000000000
}

>> parse "c3VyZS4=" [any [4 base64] [3 base64 #"=" | 2 base64 2 #"="]]
== true

ok, thanks

you may want to compare this to actual debasing to see which is faster 
on a big string. debase being native it might actually be faster.

(though, the allocation and copy of data could be significant enough 
on a big string for something like this to be worth it...)

yes, I suppose also it can't be 100% foolproof, since you can enbase 
nonsensical data?

well... enbase just converts binary (8-bit) data to a form that is 
ascii printable. it does not say anything about what the 8-bit data 
contains.

If I need case sensitive SWITCH and still want to use string values, 
is there any other way than using PARSE/case instead?

Why PARSE? Originally, SWITCH was implemented using FIND, so use 
that implementation, replacing FIND by FIND/CASE

aha, or, maybe it was implemented using SELECT? Then, you can use 
SELECT/CASE.

switch is native, isn't it? and has no /case.

SWITCH is native only recently

find an older one

it's easier to use the parse instead:
>> parse/case "A" ["a" (print 1) | "A" (print 2)]
2

But I consider it as a big limitation of the SWITCH function.

switch: func [
    "Selects a choice and evaluates what follows it." 
    value "Value to search for." 
    cases [block!] "Block of cases to search." 
    /default case "Default case if no others are found."
][
    either value: select cases value [do value] [
        either default [do case] [none]]
]

replace SELECT by SELECT/CASE

and, use the [throw] function attribute, when in R2

the parse version is almost 3x faster

that is fine, (btw, I found the original switch source in one of 
your own comments;-)

http://www.rebol.net/cgi-bin/r3blog.r?view=0090

:-D

the later switch doesn't work like a select anymore.. it finds and 
then skips to a block, which allows multiple keys per block.  its 
very usefull.

Aha, did not notice that, not using it extensively

I use it almost exclusively in my stuff, although I've been using 
case a lot more lately.

Any thoughts on what should happen if you modify the cond-block of 
a WHILE while executing the WHILE?

Take this code for example:

    a: 0
    b: [a < 5]  ;; cond-block of WHILE
    c: [        ;; body-block of WHILE
         print a
         a: a + 1
         insert b false   ;;  modify the cond-block
         ]

    a while b c

R3 ... acts as if the code were:
     a while copy b c
  so the modification to b is ignored

R2/View and R2/Core Crash with a corrupt datatype 192 (or 64)


None of them seem to allow inflight modifcation of the cond-block.

I have a suspicion that the answer would differ based on whether 
the modification is performed in the cond block vs. the body block, 
but if what you describe is true then that would make sense. I'm 
going to run some tests.

The trick of course is that modification of the INSERT and APPEND 
variety can result in reallocating the block, and native code wouldn't 
necessarily notice the change since it would still be referring to 
the old version. It's not quite the same thing with REMOVE and CHANGE 
style modifications.

In R3:
>> while b: [change back tail b false true] [1]
== none
>> while b: [remove back tail b false true] [1]
== none
>> while b: [false true] [print 1 remove back tail b]
1
== []
>> while b: [true] [print 1 append b false]
1
== [true false]
>> while b: [append b false true] [print 1]
== none
>> while b: [append/dup b false 1000 true] [print 1]
== none


Clearly modifications seem to work in R3, at least to the tail (which 
is the portion of the block that would affect the result), even if 
a realloc is necessary.

Your code made inserts at the beginning of the code block, which 
wouldn't affect the result since it is only the last expression that 
matters in the cond block (except for side effects).

>> 1 ** 2
== 1.0
>> help **
USAGE:
    number ** exponent

DESCRIPTION:
     Returns the first number raised to the second number.
     ** is an op value.

ARGUMENTS:
     number -- (Type: number)
     exponent -- (Type: number)
>>

what's the justification of returning a decimal value?

for retu..

I guess I should just use shift/left instead of '**

** uses a decimal operation, so if it didn't return a decimal it 
would have conversion losses. For powers of 2 SHIFT is better.

I was thinking of powers of integers so that makes sense

Mean WHILE.....Thanks for debugging my example, Brian. I got confused 
and reported the wrong thing.


Yes -- on R3 if is possible to modify the cond-block and that modification 
will be respected. That''s how I hoped it would be.


It is not possible to _replace_ the cond-block by reassigning its 
word. But that's understandable and probably exactly what we'd all 
want:

   cb: [true cb: [n < 3] true]       ;; cond-block that overwrites itself
    n: 0

    while cb [n: n + 1 print [n cb]]   ;; WHILE that uses original cond-block

Re: ";; cond-block that overwrites itself" I am having trouble with 
this formulation, since it is not true; the block (when evaluated), 
just changes what the CB variable refers to, but surely does not 
everwrite itself.