On 12/16/1999 at 12:17 AM [EMAIL PROTECTED] wrote:
[...]
> On the other hand, I prefer to keep the vocabulary needed to describe
> REBOL
> to a minimum. I also like to exploit the similarity of principles, to
> keep
> the volume of information needed to reason about REBOL to a minimum. If
> we
> just stick with the idea that the current position of a series is
> local,
> whereas the data storage is global, we can consider a series to be
> something similar to a function. The idea of global and local values,
> persistent changes and temporary changes arises in the same manner,
> when we
> discuss the behavior of functions:
>
> For instance, we always warn newbies that each time the following
> function
> is called, digits will be added to a string referenced by a local word,
> unless make string! or copy "" are used to guarantee a fresh string
> each
> time the function is evaluated:
>
> >> f: func [/local a] [ a: "" for i 1 6 1 [insert tail a i] print a]
> >> f
> 123456
> >> f
> 123456123456
> >> f
> 123456123456123456
>
> The word 'a is local, but the string it references, like all literal
> values, is global. I like the idea that you can think of a series as
> somewhat analogus to a function. The data-storage is global, whereas
> current position is local.
[...]
> a) Since REBOL really isn't all that complicated, a mathematically
> precise,
> computer language scientifically comprehensive account of REBOL will
> just
> make REBOL appear more complicated than it is and will make it more
> difficult for REBOL's target audience to take conceptual possession of
> REBOL.
>
> b) Perhaps the Tokyo super train - which is controlled by fuzzy logic -
> demonstrates that if we approach understanding REBOL with more of a
> fuzzy
> approach, we'll get our jobs done faster, if not to say just in time.
> Look
> for similarities and identify enough distinguishing details to rapidly
> implement a system that is close enough to expectations to be
> acceptable.
>
> Anyway, I'm glad you brought it up, I'm always happy for an opportunity
> to
> reflect conceptually on what I'm doing all day with REBOL and I'm sure
> that
> continuing this thread will provide different people with different
> insights as and when they need them, occassionally.
>
> Elan
>

I think that the effort to find an adequate terminology is quite reasonable.
It can't be considered as the opposite of being simple. Actually, the best
terminology is, IMHO, a terminology, that is simple and correct.

Let's get to the above example, but let's use a little bit different code:

f: func [/local a b] [ a: "" b: copy "" for i 1 6 1 [append a i append b i]
print a print b]
>> f
123456
123456
>> f
123456123456
123456
>> f
123456123456123456
123456

Let's have a look at A and B above. We see, that they are exactly the same
as long as "scope" is concerned.

(Scope means the part of the code where you can use A and B to access the
data. The possibilities are "global" vs. "local".)

We see, that both A and B are "local" to F in that sense (no sign of
globality present).

So, where's the difference?

We must turn to a different notion, the "lifetime" of data, which can be
described in terms like "static" vs. "dynamic".

So, where is the difference between A and B? The correct answer is:

B is created dynamically when the interpreter encounters the expression:

copy ""

, which is a sign of dynamic data creation.

, but A is not created when the interpreter encounters the expression:

a: ""

, because in the latter expression the data known as A only get it's name A.

The legitimate question arises: "When is the A data really created?"

The correct answer IMHO is as follows: data A (although not having that
name) gets created when the interpreter LOAD's the F's code. Any
modification to A data then persists until the data doesn't get
garbage-collected, which may happen e.g. when F gets GC'd.

So, the difference between A and B lies in the fact, that the creation of B
is "dynamic" as opposed to A, where the creation is "static" and the notions
of "global" vs. "local" are misleading in this case.

Ladislav

Reply via email to