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-
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
