World: r3wp

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

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