Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: ... Scope yet again...

From: joel:neely:fedex at: 11-May-2001 8:38

Hi, again, Larry, On a different tack (different enough to warrant a different reply)... Larry Palmiter wrote:
...
> 2) Sub-objects exported with your do [] construct or by using SET are > not really "embedded", the words which reference them are global, but > the words contained in their definition blocks are bound to the > context of the object in which they are created. To me it is similar > to this example: > > >> b: [] repeat j 3 [use [x][x: j append b 'x]] > == [x x x] > >> b > == [x x x] > >> reduce b > == [1 2 3] > > The word b is in the global context, it's value is a block which > contains the words x, x, and x each of them created in a different > unnamed context. >
I find this example fascinating, especially in view of the behavior of
>> ff: func [arg cond /local locvar] [
[ 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] [ ] [ ]
>> ff 1 true
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-