World: r3wp

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.

err: 'cb and overwrite

we need to make distinction between overwriting a variable, and overwriting 
a block

Sunanda should know better.

Perhaps WHILE could also accept a word! for its condition parameter, 
and when it does, evaluates it to the block it is expected to reference 
before continuing to evaluate as usual.
Eg.
	while 'cb [...]

That functionality is pretty easy to by evaluating the word inside 
the condition block yourself.
eg.
	while [do cb] [...]

so I don't think it's really necessary.

What should this function be called, and what options does it need?

change-in: funct [key value] [
    either a: find block key [change next a :value][
        repend block [key :value]
    ]
]


It basically implements the a/key: value operation of maps, but for 
series.

Andrew Martin chose ASSOCIATE for that sort of thing:
   http://www.rebol.org/view-script.r?script=associate.r

SQL calls it MERGE, because UPDATE was taken.

I suppose you had FUNCT [BLOCK KEY VALUE] in mind for the above, 
Brian? If so, I think I like MERGE much, but every now and then someone 
has to suggest ALTER

I vote for UPDATE. It should be able to handle more than ports, even 
if the behavior isn't exactly the same.

Yes, of course, Gregg, UPDATE only working on ports seems indeed 
too limited for such a nice word. 


BTW, Brian, is the above behaviour to return after the change for 
updates and at the insertion for inserts intended?

>> update: :change-in
>> attributes: []
== []
>> update attributes 'color red
== [color 255.0.0]
>> update attributes 'color blue
== [] ; or rather [color 0.0.255]

its the natural completement to SELECT, so UPDATE is quite natural.

On the other side, to answer your question, it's related to SELECT 
and should probably support most, if not all, of SELECT's refinements, 
too. That's a bit of a stretch, because for ports UPDATE probably 
needs to be very fast and can't be thwarted by too complicated refinement 
handling?

Ah, Max, you're first ;-)

hehe

UPSERT

Widely used term (in database circles) for this operation.

I wasn't the original author, but I'm willing to bet that the return 
value wasn't considered. The best behavior would be to return the 
head.

Same for the [block yey value] thing :)

Andreas, the recent SQL standards call this operation MERGE, partly 
because UPSERT sounds terrible.

Can anyone suggest a free tool that can be used to decrypt files 
that have been encrypted using Rebol's Rijndael using a 128 bit key?

And not Rebol!