World: r3wp

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

I don't know why I put it there.. did I try and somehow couldn't 
make it work or just assumed I need it

I suppose the latter

probably yes

maybe this behaviour was bugging me .. because I know I use the order 
of things in any or all a lot of times to avoid null errors and similar 
.. and any-is? always preprocessed all elements

so, now you know, why I "whine" against using REDUCE by default in 
mezzanines ;-)

:)

reduce is evil !! :)

yes, especially since we can reduce on demand as we are send args 
 : -)

BTW, (shameless plug) I am using INCLUDE instead of DO from the console 
when doing scripts, since I have an extensive INCLUDE-PATH, so I 
don't have to write the directory of the script, just its name

hm.. that is usefull .. now I am copying my common library files 
around , then I could have them all in one location

not necessary at all ;-)

(my user.r first does %include.r, that is the most frequently used 
script here)

Max prefers his Slim, I know

BTW, Max: how old is the newest Slim version?

very ;-)  I fixed a little issue with interdependant libraries last 
month, but a part from that it has remained the same for years.

slim is practically the same as module in philosophy, and in many 
areas the same functionaly too.

yes, I remember our discussion about it

I use slim and prebol together within the sdk, it works very well. 
 I should use %include.r though, its much better and would solve 
a few little complexities I have with using the prerebol.r

when I get to working on the linking within distro-bot, I'll use 
%include.r instead of prebol.r... I also want to integreate %run.r 
from rebol.org into it.

it is quite surprising for me, that Carl is not a fan of the PREBOL 
approach, taking into account, that he invented it. I had a version 
of INCLUDE before PREBOL came and adapted it to the PREBOL standard 
afterwards

Carl's mind is too dynamic for static linking.

...but in REBOL nothing is static

prebol is... you have to build your script before executing it.... 
which is why I prefer %include.r

aha, that is what you mean