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

[REBOL] Re: Embedded Object and Scope yet again...

From: joel:neely:fedex at: 12-May-2001 0:13

Larry Palmiter wrote:
> Hi Joel > > > IMHO, using DO or USE is a more general mechanism, as it actually > > allows you to "embed" references wherever you wish, instead of > > being limited to the global level as with SET. For example: > > > I'm a little puzzled by your remark. SET is not limited to binding > in the global context. Rather, the target word is simply searched > for up through the context hierarchy... >
Excellent! Clearly I needed to do a little more REBOL nuclear physics. Thanks for the correction!
> One limitation of SET is that it will only take a WORD or BLOCK as > argument, it will not accept a path. In that sense your DO construct > is more general. > > It is perhaps worth noting that in reading thousands of lines of > "internal" port, view, vid, and desktop code, I don't recall ever > seeing USE used, perhaps because it was broken (exported refs > generated a GC crash)for most of the last 2 years. >
I'm sincerely hoping that the "indefinite extent" bug is a thing of the past, although Ladislav's analysis of looped-use versus recursive-use makes me wonder if all the snakes have been chased out of the woodpile. AFAICT, saying ... use [foo baz quux ...] [ ; more activity here ] ... *should*be* equivalent to ... do func [/local foo baz quux ...] [ ; more activity here ] ... according to the available documentation. As described. However, we can test the looped-use versus recursive-use cases with this replacement and see a difference:
>> bb: []
== []
>> repeat i 3 [do func [/local x] [x: i append bb [x]]]
== [x x x]
>> bb
== [x x x]
>> reduce bb
== [1 2 3] Thus far, we have results consistent with the idea that USE (and the DO FUNC /LOCAL replacement) will create a new context with each evaluation. Now, for the recursive case:
>> ckscope: func [argvar cond /local locvar] [
[ locvar: argvar + 1 [ do func [/local privar] [ [ privar: locvar + 1 [ print [argvar cond locvar privar] [ if cond [ckscope argvar + 10 false] [ print [argvar cond locvar privar] [ ] [ ]
>> ckscope 1 true
1 true 2 3 11 false 12 13 11 false 12 13 1 true 2 3
*THAT* result is consistent with dynamic scoping (e.g., in LISP) and with the expectations set up by the documents. Therefore, I'm swayed by this experiment (and by Ladislav's explanation) to regard the behavior of USE in this situation to be unfortunate at best and possibly buggy. Again, I'll have to say that I don't know whether this difference was intended by RT, or is a case that didn't get thought about, or is a case that was thought about but not viewed as having enough priority to be dealt with.
> Clearly, it is not really needed to create complex REBOL programs. >
The above rewrite demonstration clearly shows that we can get along quite nicely (more nicely, with present behavior) without USE in the dictionary. However, REBOL is riddled with examples of trivial bits of syntactical sugar that have even less explanatory value (IMHO). Consider: MAKE FUNCTION! vs FUNC vs FUNCTION vs DOES MAKE OBJECT! vs CONTEXT (a *very* unfortunate choice of words, in my humble opinion, considering that "context" is already a critical and not-well-explained and not-first-class REBOL concept) ...and I'm sure you could extend the list at least as quickly and as far as I could... The ability to state succinctly At this point I want to create a new scope for some lexically- local variables that will be invisible to the rest of the code. is a nice convenience. I've certainly seen my share of FUNCs that have a longer-than-convenient-to-remember list of local variables which are all declared in the argument block (to protect the global namespace) even if few of them are widely used throughout the body of the function. I really believe that being able to keep the scope of a variable as small as possible enhances readability and comprensibility. I'm just sad that the present implementation of USE raises as many questions as it answers. (And, as always, I'd love to be corrected if someone has a clearer mental model to offer.) -jn-