I think all of them have some problems including mine. Doc: Your version stuck if no match: >> replace-deep x: [a] 1 2 ;waits for ever
My version stucks if new value is a block that includes the search value: >> replace-deep x: [a b [b] b] 'a [a b a] ;infinite loop
Rebolek: Your version doesn't work for some values >> replace-deep3 x: [1 2] 2 3 ; x stays unchanged
Rebolek
Oh, integers...
DocKimbel
It might be very complicated to achieve it using PARSE in Rebol2 due to the lack of escaping mechanism for words and integers like QUOTE in Red and Rebol3.
In Red, this version passes all the tests:
replace-deep: func [s [any-block!] value new /local rule pos][ rule: [any [pos: quote _ (pos/1: new) | into rule | skip]] rule/2/3: value parse s rule s ]
probe replace-deep x: [a] 1 2 probe replace-deep x: [a b [b] b] 'a [a b a] probe replace-deep x: [1 2] 2 3
[a] [[a b a] b [b] b] [1 3]
Rebolek
Endo's replace function (m: any-type! and then check for values in paren!) can do it
Nenad, your version is missing ANY-STRING! rule before INTO RULE rule to ignore string!s, otherwise INTO will try to parse inside them.
DocKimbel
Indeed, with an INSERT/ONLY instead of INSERT, it would pass the second test.
Any-string!: good point.
Endo: the [ | skip ] part of your rule looks superfluous.
PeterWood
How does the /only refinement of find work?
Rebolek
>> find [a b c d] [a] == [a b c d]
>> find/only [a b c d] [a] == none
>> find/only [[a] b c d] [a] == [[a] b c d]
Pekr
for nested blocks?
C: [ 1 [ 2 3 4] 5 6 ]
find/only C [2 3 4] ;--- should be find/deep then imo :-)
PeterWood
Thanks Rebolek and Pekr
Endo
I wrote some optimization questions in munge! group but not directly related to MUNGE, so I'll be appriciated if anyone can take a look and give sme ideas.
Ashley
INSERTing into a [large] block! is significantly slower than APPENDing. Likewise, REMOVEing from the head is much slower than the tail. For this reason it is often faster to create a new block than modifying [entensively] an existing one.
Endo
Doesn't it strange that THROW throws an exception, not CATCHed but execution stops where THROW is if block executed by CONTEXT >> b: [print "1" throw "catch!" print "2"] print catch [do b "3"] 1 catch!
>> b: [print "1" throw "catch!" print "2"] print catch [context b "3"] ; unexpected result when using CONTEXT 1 3
I think it is a bug on R2, R3's result is 1 catch! for both.
amacleod
What's the best way to search a block of blocks for specific values. Is there a more efficient way other then looping through each block? would key-value scheme make it easier?
Bo
amacleod: We just were discussing that in the !REBOL3 group.
amacleod
k, thanks
Sunanda
Gregg suggests this is a good group to post puzzles.....Actually, it is a real situation for which I wrote some grossly inelegant code. My code works, but it hardly shows off the beauty of Rebol or the power of Parse. So looking to see if anyone can do better than my 15 or so lines of procedural code....