World: r3wp

That is what !REBOL3 is for. Once the ideas are established we make 
topical groups for them, like !REBOL3 Graphics.

Formal proposals go in CureCode (eventually, after discussion in 
!REBOL3 or on a blog or wiki page).

well, where is generic *using* R3 group then?

anyhow... its just that more groups is faster than really big ones, 
so separating the use and proposal discussions seem to be a good 
thing in my mind.

Brian, in

http://www.curecode.org/rebol3/ticket.rsp?id=1744&cursor=2

you wrote: "We already have local THROW and RETURN"


If we do, I must have missed them, knowing only the global variants. 
Can you point me to them?

I would say, that this looks as a terminological misunderstanding 
to me.

I explain it for RETURN, but the case of THROW is similar. Normally, 
when you use RETURN in REBOL, it is a global function that does something. 
I demonstrated, that it is possible to have a similar construct (possibly 
even using the same name), which could work as "local" in the sense, 
that it would be assigned to a locally-bound 'return word. Such a 
"local RETURN" would, in fact, be able to "jump many levels up", 
not just one level, as the current global RETURN does, since it would 
be tied to its "function of origin".

return/to

instead of "tied" I should rather have said "bound"

(i.e. no refinement is needed)

>> a: [ b [ c [ 1 ]]]
== [b [c [1]]]
>> d: 'b
== b
>> e: 'c
== c

using a, d, and e, how would I get the value "1" ?

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.