World: r3wp

in-shadow-context: use first system/words['some-word]

then bind to 'some-word. somewhat  expensive, but you do it only 
on input. 

Escapes: it  does not go into #[object![..]]. I have  a function 
which does  that too.  ifthe user can do a  stringwith a new word, 
that  word is still global.

and  then fill your functions in.
use first system/words reduce[f1: (:f1) ... 'some-word]

no,  compose.

UNBIND might help handling such constructs, maybe

It would. do we have it?

I hope in  r3

yes, it has been offered for R3 in a blog

Yes, I want to bind it to a different context to be safe .. so exactly 
how do I create this different context for all the math stuff?

>> a: context compose [
[    (to set-word! '+) get in system/words '+
[    ]
>> a/+

** Script Error: + expected value1 argument of type: number pair 
char money date time tuple
** Near: a/+

(don't ask me why +: is not a valid set-word)

another option:


math-words: [+ - * / ** = == =? < <= > >= and or xor square-root 
negate]
math-words: use math-words reduce [math-words]
foreach word math-words [set word get in system word]
etc.

the last line should have been:

    foreach word math-words [set word get in system/words word]

yes. but keep in mind bind ignores functions and objects, so you 
must  recurse into them too.

can anyone confirm that these two statements should return the same 
value for the same blk and val?

select blk val
second find blk val


as long as val does exist in blk.

does select reduce both args before selecting?

my god... REBOL is going nuts!  I have a situation where the above 
is not true...  and the select pairs are [aword an-object bword another-object]

and only the find works... if I try to select using 'aword   it always 
returns none

print first reduce blk

raises an error as expected since aword is not defined anywhere!

help! this is tooo strange!

relax... rebol is probably not going nuts. There is a reason somewhere.

quickly make a little example file which demonstrates the problem 
using a new console.

hehe... its just that no probing or printing reveals anything out 
of the expected.

using a new console, things behave as expected... which is why I 
am wondering why they don't in the running code

(using a block with simple values, the two lines above act as I would 
expect)

Ok, then fork the entire code and cut away chunks until it no longer 
displays the problem.

ehh impossible... we are talking bout an entire app here... 200-300kb 
of code. probably... and the problem occurs within an event loop.

but look at the simplicity of the two lines above... can you image 
a way in  which  the select would return none and the find would 
return the object?

(not impossible - that technique works when I can think of nothing 
else).

A confusion between lit-words and words maybe ?

hum...

unfortunatetely, I can't print the block, cause the objects have 
nested objects, and that causes an out of memory err, If I try to 
mold it  :-(

write clipboard:// mold/all blk
and paste it (and mold/all VAL) into a new editor window.

Ah..

the actual app takes very little ram, but the objects, have bidirectional 
linking... so I guess the mold never reaches the end.

Ok, then, for your test, before molding, process each object to set 
none all fields which could recurse.

hum... I'll try my inspector... maybe it can help me a bit...

oops... closed altme by mistake... the inspector basically has the 
same problem...

I'm trying some block alterations...

wrt lit-word vs word... find is reacting as expected.... select is 
numb like a frog on ice

Maybe check that BLK really has the expected types in the correct 
order.

oh my... I just found it... 

 same?  :select get in system/words 'select
== false

seems some code redefines select somewhere...   >:-(

well, thanks for bearing with me... your words vs lit-words  idea... 
got me probing differently..

strangely, I can't trace where that is happeneing... willl try to 
protect the word...

well, as usually protect doesn't help... arrgh.

(as usuall)

protect doesn't help ? Is SELECT redefined despite being protected 
?

well, protect, only helps within the global context... which is why 
I wish there was /HARD mode which protected ANY setup of a specific 
word.

probably also can protect word within a context... but at that point, 
the damage is usually done.

I've discoverd another way to discover where a set occurs... within 
objects, you look at the first... and the natural order of words, 
is a telling clue...