World: r3wp

and its data syncronizing that I'm concerned with...

What am I doing wrong here??
given a block of blocks: 
[

[67 "FFP Vol.2 - BASIC ENGINE OPERATIONS" "Chapter 1 - INTRODUCTION" 
"1.1"]

[69 "FFP Vol.2 - BASIC ENGINE OPERATIONS" "Chapter 1 - INTRODUCTION" 
"1.3"]

[68 "FFP Vol.2 - BASIC ENGINE OPERATIONS" "Chapter 1 - INTRODUCTION" 
"1.2"]

[71 "FFP Vol.2 - BASIC ENGINE OPERATIONS" "Chapter 1 - INTRODUCTION" 
"1.2"]

[268 "FFP Vol.2 - BASIC ENGINE OPERATIONS" "Chapter 1 - INTRODUCTION" 
"1.2"]

[721 "FFP Vol.2 - BASIC ENGINE OPERATIONS" "Chapter 1 - INTRODUCTION" 
"1.2"]
]

Using alter to remove each block in a loop:
 foreach z a [alter a reduce [z] probe a wait 3]

with a being the blocks above

It seems to work for the first two but than skips a block and than 
fails...

same result using find-remove:

foreach z a [if find a reduce [z] [remove a reduce [z]]]

I get three left over blocks


i I run it again I get one left over block and f I run it a final 
time it reoves the final block

foreach will advance to the next index whether or not the series 
was modified:
>> D: [1 2 3 4 5 6 7 8 9]
== [1 2 3 4 5 6 7 8 9]
>> foreach X D [remove find D X]
== []
>> ? D
D is a block of value: [2 4 6 8]

Using remove-each is better for this:
>> D: [1 2 3 4 5 6 7 8 9]       
== [1 2 3 4 5 6 7 8 9]
>> remove-each X D [integer? X]
== []
>> ? D
D is a block of value: []

I'm a dope...Thanks for the clue...
I used another 'variable' to what I needed...it works now!

Modifying a series you're iterating over is always risky. Not only 
do you have to make sure you get it right, but there is always a 
possibility that iterators might change their behavior.

...

rebol can be viewed also as Lisp without parentheses.. it can edit 
it's own code/data structures without any problem... so why doesn't 
rebol have something like macros ?? :)

well, any Lisp-er not knowing REBOL would telly you: macros are absolutely 
necessary ;-) But the fact is, that REBOL actually *does* have macros, 
since REBOL is its own macro-language

(REBOL *does not need macros*, but ssh, don't tell LISPers, they 
would say, that you always need them)

nice way to put it... I hadn't thought about it that way.

I was already thinking a little that you probably don't really need 
them since you can change/generate code structures at startup or 
"JIT" and "cache" them ... but it was just a hunch.. not something 
I could imagine all the way down ...

but are there things where you could do more without perf. penalty 
if there were macros?

perf. penalty: REBOL, due to its "philosophy", is an iterpreted language, 
which is a "performance penalty" against compiled languages, yes. 
But who cares? I have seen many compiled programs much slower than 
what I was able to write in interpreted REBOL.

I sometimes have some stupid ideas of changing code and blocks into 
something else but I don't have a totally clear view yet if that 
is ok to do and what would be the right way to do that.

well, it takes experience, but you are doing well, I guess

yes, I am not fanatical about straight up performance, I agree with 
you abut speeds

I have one example ... it was fun to make but all in all doesn't 
seem a good idea so I don't use it now (I think it's not really robust 
and it gives strange errors.. not 100%), I am not sure.. would classic 
macros make it more possible, this all make changes at runtime: 

any-is?: func [ 'PRE s ] [
	while [ not tail? s ] [ s: next insert s PRE ]
	any reduce head s
]
; usage
if any-is? empty? [ d-y d-m d-d title category ]
    [ print "Error some value is empty: " fail: true ]
if any-is? positive? [ apples oranges kiwis grapes ]
    [ print "There is some fruit in your fridge" ]
if any-is? [ not empty? ] [ a b ] [ print "yup" ]
if any-is? [ 5 < ] [ num1 num2 ] [ print "yup" ]
if any-is? [ 5 < length? ] [ str1 str2 ] [ print "yup" ]

(I never used Lisp or Scheme for anything serrious , so I don't know 
macros in practice)

hmm, interesting approach

janko, that's a great function!

(well I don't know if macros would enable this at all since I change 
the runtime data (to code) and macros as I understood happen at compile 
time)

I must say, that I don't like the non-transparent argument passing 
method

(meaning I would use func [PRE s] as the spec instead)

moreover, you can copy the S block, if that is what causes trouble 
(which may be indeed the case)

Maxim: hm .. I am not sure :) .. as I said I don't use it now .. 
it just has historic value ..

Ladislav: aha.. I understan what you mean .. yes I am not sure too.. 
it's fancy but not best for clear usage

did you test it with s: copy s?

I am not sure what was the problem .. it's a while since I used it 
.. I just thought this function can't be good ..

then there is the inclusion problem: this algorithm is O(n ** 2), 
which is slow, but for small blocks it is probably OK

it works in general cases and I have it in some older code .. maybe 
errors got a little strange if datatype didn't match the PRE function 
... like empty? none ... I can take some time and test it again

yes, of course, the function has to be able to do the job for all 
data in the block

yes.. I understand that .. I thought that in such case an error was 
untiuntive .. but I tried and it looks like it should .. ok .. so 
I don't know if anything is wrong with it


>> any-is? empty? [ "asd" "Asdas" ]
== none
>> any-is? empty? [ "asd" "Asdas" "" ]
== true
>> any-is? empty? [ "asd" "Asdas" "" none ]

** Script Error: empty? expected series argument of type: series 
port bitset
** Where: any-is?
** Near: empty? none
>>

If you don't see anything massively wrong with it I will start using 
it again and I will see .

the copy is a good idea though, cause if you use it for real data, 
some functions can mangle the content of the block.

I'd even do a copy/deep

aha.. yes .. this is true.. I will add it

copy could optionally be a refinement, if you know that the test 
isn't destructive... cause copy will be a performance hit .

copy/deep isn't necessary, since only the top level is modified (unless 
the PRE argument isn't modifying)

(unless the PRE argument *is* modifying)

hmm, the behaviour looks strange

what do you mean?

aha, why don't you use:

any-is?: func [ 'PRE s ] [
	while [ not tail? s ] [ s: next insert s PRE ]
	any head s
]

you mean without the reduce?

if it works without it it would bebetter.. then it would also be 
lazy as any is

>> any-is? empty? [ "asd" "Asdas" "" none ]
== true

yes :) I noticed on that example also that it doesn't work lazy as 
any .. but I didn't know I can remove reduce

well, it's REBOL ;-). (*Don't* use REDUCE unless absolutely necessary, 
at least I do it that way)

aha, it really works as it should now