REBOL's clear and Scheme's clear are not analogous. REBOL's clear doesn't
clear the stored data, it "disconnects" 'list (your example) from it and
eventually the garbage collector reclaims the unused memory where the data
is stored. REBOL's 'clear is a lot faster, especially for large series. If
you want list2 to reference the same data, but copied to a fresh location,
use copy, i.e., list2: copy next list. This allows you to mess with 'list
without affecting 'list2. If one insists on establishing two words
referring to the same data, then before one clears one he should 'unset the
other. Perhaps 'unset should be used in place of 'clear. Here's some
diddling around with unset.
>> list1: [1 2 3 4]
== [1 2 3 4]
>> list2: next list1
== [2 3 4]
>> unset [list2]
>> list2
** Script Error: list2 has no value.
** Where: list2
>> list1
== [1 2 3 4]
>> list2: next list1
== [2 3 4]
>> unset [list1]
>> list2
== [2 3 4]
>> head list2
== [1 2 3 4]
>> list1
** Script Error: list1 has no value.
** Where: list1
>> unset[list2]
>> list2
** Script Error: list2 has no value.
** Where: list2
Note unset-ing list1 doesn't seem to bother list2
>>
Russell [EMAIL PROTECTED]
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, December 12, 1999 1:45 AM
Subject: [REBOL] RFF: empty? for blocks Re:(5)
> On 13-Dec-99, [EMAIL PROTECTED] wrote:
>
>
> >There is one painful exception that does not fit in this metaphor. That
is
> >the reported case:
>
> >>> list: [1 2 3 4]
> >>> list2: next list
> >>> clear list
> >>> list2
> >== [2 3 4]
>
> >Here list2 should not report [2 3 4]. It should report []. Since the
movie
> >contains zero frames, list2 should not recall that there were frames at
the
> >time it was assigned the value: next list. To accomplish that, list2 must
> >negotiate its value with the movie when it reports the frames it is
> >assigned to. If it only sticks to its own offset into the block that was
> >cleared, it apparently finds the old values because they were not
> >physically removed.
>
> >List2 becomes painfully aware that the movie was modified when it tries
to
> >respond to stuff like length?:
> >>> length? list2
> >** Script Error: Out of range or past end.
> >** Where: length? list2
>
> It seems to me the problem is the command "clear". Consider the analogous
> sequence in Scheme
>
> : (set! list1 '(1 2 3 4))
> #[undefined]
>
> : list1
> (1 2 3 4)
>
> : (set! list2 (cdr list1))
> #[undefined]
>
> : list2
> (2 3 4)
>
> : (set! list1 '())
> #[undefined]
>
> : list1
> ()
>
> : list2
> (2 3 4)
>
> : (length list2)
> 3
>
> Note that in Scheme there is no destructive command "clear", instead list1
has
> to be "set!" to the empty list, which is a new empty list and leaves list2
> unaffected. Shouldn't "clear" work the same way? i.e. create a new empty
list.
>
> Brent Meeker
>
