... Scope yet again...

Not at all, that is only a Use bug. Use really creates a new context every time it is invocated (a fresh 'usevar word everytime Use is invocated). The only problem with Use is, that it modifies its second argument (the Body block) when it binds it to the newly created context. This is the source of the problem in the Ff function above, where the Print function doesn't have access to the correct 'usevar word, because the word gets modified by the subsequent call to Use. To be more concise, the body of the Ff function is Self Modifying. To repair the code you can replace Use by its non-modifying counterpart: nm-use: func [ { A non-modifying use version. Defines words local to a block. } [throw] words [block! word!] {Local word(s) to the block} body [block!] {Block to evaluate} ] [ use words copy/deep body ] After the replacement, the Ff function will no more be Self Modifying and it will work fine. Another interesting example: b: copy [] rep: func [n] [if n <= 3 [append b 'n rep n + 1]] rep 1 b ;== [n n n] reduce b ;== [1 1 1] If we use E-func instead of Func as below, we get: b: copy [] rep: e-func [n] [if n <= 3 [append b 'n rep n + 1]] rep 1 b ;== [n n n] reduce b ;== [1 2 3] E-func is a "repaired" Func and you can find it in http://www.sweb.cz/LMecir/highfun.r

The new context is created every time Use is evaluated, but Use modifies the Body block, which is a source of trouble (an invisible Self Modifying Code). Regards Ladislav P.S. I would like to suggest everyone, who is interested, and didn't read http://www.sweb.cz/LMecir/contexts.html , or http://www.sweb.cz/LMecir/rep.html to have a look at these.

...

I find this example fascinating, especially in view of the behavior of

[ use [usevar] [ [ locvar: arg + 1 [ usevar: arg + 2 [ print ["in :" arg cond locvar usevar] [ if cond [ff arg + 10 false] [ print ["out:" arg cond locvar usevar] [ ] [ ]

in : 1 true 2 3 in : 11 false 12 13 out: 11 false 12 13 out: 1 true 2 13 One might infer from your example that encountering USE causes an unnamed context to be created and that leaving the body of the USE causes that context to become inaccessible except via any persistent exported references -- every pass through the loop gets a "fresh" X instead of using the one from the previously existing USE context. However, the behavior of FF implies that the recursive invocation of FF did *not* get a fresh USEVAR, but instead somehow had access to the one in the context previously created. So... did that "context previously created" come into existence when the upper/outer invocation of FF occurred, or during the execution of FUNC when the body of FF was created, or ... ? REBOL is a fine, interesting language. I like REBOL. REBOL is good. (Having issued sufficient disclaimers... ;-) REBOL is *NOT* simple! And, before anyone can respond with the old "you just haven't got it yet" argument, let me clarify what I mean (based on dozens of years' experience with dozens of programming languages -- literally!) REBOL and FORTH are very much alike, in that many of the key concepts of the language cannot be understood apart from the specifics of how they are implemented. (EWD refers to this as "operational thinking", and has written much about how it contributes to complexity. I won't gild the lilly by trying to repeat/paraphrase him, but offer the URL http://www.cs.utexas.edu/users/EWD/ewd13xx/EWD1305.PDF as a "taste" for any interested parties). It may seem easy to say, "Feature X works this way..." and give a few sentences that describe how it might work. But as the list of features described that way continues to grow, AND as the number of exceptions dealing with specific combinations of features begins to grow, AND as we begin to need more specific detail on how it *DOES* work instead of how it *MIGHT* work in order for our descriptions to hold up as the features interact... Well, this way lies a combinatorial explosion of details and exceptions that one really must understand if one is to be able to describe accurately the properties of one's program. There are some simple "acid test" indicators of complexity: 1) Whenever someone responds to a question about the language by saying, "Let's try it and see what happens". 2) When someone is surprised because a feature used in a new setting exhibits some subtly (or not-so-subtly) different behavior. 3) When different someones have emphatic disagreements about what some feature "should" do. 4) When someone must respond to a question about the language by beginning, "Well, it depends..." and finally (last, but *CERTAINLY* not least), 5) When these behaviors continue to be observed, even when the "someone"s above are experienced users of the language in question. No single instance of any of these is an absolute binary switch. But the more they persist, the more their aggregate weight is an indication of lurking complexity. Again, let me be clear that I am *NOT* condemning REBOL. I do think that we (and our potential future fellow REBOLites) would benefit from clear, objective discussion that includes *BOTH* the benefits and limitations of REBOL, so that we can represent and use it realistically. (And I'd still *LOVE* to see an authoritative description of USE ...) -jn-