[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-
