Hi Ladislav
Russell [EMAIL PROTECTED]
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, December 17, 1999 4:32 PM
Subject: [REBOL] "logical" value referencing ... Re:(9)
> Hi, Russell, you wrote:
>
> But I must admit I'm "flabbergasted" at how the function 'f as defined
> immediately above, works on repeated
> applications. You proposed some ingenious "debugging" approaches, but I
> discovered another. Look at this
> console stuff:
>
> >> f: func [/local a] [a: "" insert a 1 a]
> >> source f
> f: func [/local a][a: "" insert a 1 a]
> >> f source f
> f: func [/local a][a: "1" insert a 1 a]
> >> f source f
> f: func [/local a][a: "11" insert a 1 a]
> >>
> It appears that the interpreter is modifying the source!
>
> >When the expression
> > insert a 1
> > is evaluated, 1 is inserted into the string referenced by 'a.
> >
> > Therefore, the second time 'f is evaluated, a is no longer assigned as a
> > reference to an empty string. The second time around, 'a is assigned to
a
> > string that already contains one element, namely the 1 that was inserted
> > the first time around. If you want to try that in the REBOL console, you
> > have to do the following:
> >
> > >> a: ""
> > == ""
> > >> head insert a 1
> > == "1"
> > >> a: "1"
> > == "1"
> > >> head insert a 1
> > == "11"
> > >> a: "11"
> > == "11"
> > >> head insert a 1
> > == "111"
> >
>
> The above is certainly correct, as shown by the 'source f results. But
I'm
> still amazed.
>
> It surprises me that the interpreter knows that "" does not refer to an
> empty string, but to an existing string already referenced by 'a, except
in
> the first usage whre 'a has no value! I would consider this as a bug, if
so
> many smart people were'nt
> upset about it!
>
> Except for the problem of initialization of 'a for the first execution of
> 'f, 'f behaves as though it had been defined:
>
> f: func[local/ a][a: a insert a 1 a]
>
> Or as
>
> f: func[local/ a][insert a 1 a]
>
> Try the following varieties:
>
> f: func[local/ a][a: [none] insert a 1 a ]
> f: func[local/ a][a: reduce [none] insert a 1 a]
> f: func[local/ a][a: reduce "" insert a 1 a]
************* In the above, I made a typo the arg blocks should be [ /local
a]
>
> in the first [none] acts the same as "", but in the second and third
[none]
> and "" don't give the same result!!
> If it walks like a bug and talks like a bug, isn't it a bug?? It disturbs
> me that executing f changes the result of
> source f
>
> I agree; that disturbs me!
>
> [L]
> See this example code:
>
> a: ""
> body: append append/only copy [b:] a [print b]
> insert a "1"
> body
>
> Results:
> >> a: ""
> == ""
> >> body: append append/only copy [b:] a [print b]
> == [b: "" print b]
> >> insert a "1"
> == ""
> >> body
> == [b: "1" print b]
>
> Now, you can tell: the interpreter modified BODY! Is it right? The answer
> is: no, BODY wasn't modified, but it contains a, which got modified. The
> same is true for your example: the interpreter doesn't modify the source
of
> F, but it modifies the second element of the F's source.
Assuming "source of F" means the same as "F"s source", your last sentence
seems self-contradictory.
Your example doesn't mirror mine, as you have changed the value associated
with a word, 'a,
whereas in my example F's source has changed the string "" to "1", etc!
>
> The reason for your surprise lies in the fact, that the expression:
>
> a: ""
>
> doesn't mean:
>
> Create a string "" and give it the name A.
>
> It means this:
>
> Give the name A to an existing string, which was created when the F was
> created and is contained in F's body as it's second element. Then, there's
> no surprise, that the source of F looks different if we modify it's second
> element through modifying A.
It seems to me that the "" in F's original source is a literal, whereas the
interpreter treats it as the current value of 'a, unless 'a has no value
(first exercise of F), in which it "conveniently" manages to act sensibly
(IMO), and treat "" as a literal!!!
>
> Now, let's see this:
>
> a: reduce [none]
>
> This means: create a new block using REDUCE from an existing one, which is
> the third element of the function body. When you now modify A, you surely
> don't modify the third element of the function body, but something else...
I disagree with your analysis of 'reduce. See the following console
stuff:
f1: func[/locala][a: "" insert a 1 a]
f2: func[/local a][a: [none] insert a 1 a ]
f3: func[/local a][a: reduce "" insert a 1 a]
f4: func[/local a][a: reduce [none] insert a 1 a]
Now check the sources after an execution:
>> f1 source f1
f1: func [/locala][a: "1" insert a 1 a]
>> f2 source f2
f2: func [/local a][a: [1 none] insert a 1 a]
>> f3 source f3
f3: func [/local a][a: reduce "1" insert a 1 a]
>> f4 source f4
f4: func [/local a][a: reduce [none] insert a 1 a]
>>
I corrected a typo in the above. Originally I had local/, an invalid path.
Why does [none] act the same as "" in the first two examples, but
differently in the second two examples?
I'm not sure 'reduce "creates a new block. ? 'reduce doesn't say that. If
'reduce's arg is a block containing one or more expressions, it does return
a block,, but not if the arg is an expression.
I still think this is a bug. If not, it's so odd that an extensive
documentation should be devoted to it. I'm referring to "" being
interpreted as a "global string originally defined as "", but later as
whatever string happens to be at the same memory location as the original
emply string!
>
> HTH
I'm not sure I can be helped :>), but anyhow, Merry Christmas and Happy New
Millennium! (or last year of this one).
>
> Ladislav
>
Russell [EMAIL PROTECTED]
