Most of this is suppose to be the result of a bug in an implicit call
to REFORM and has been logged with Feedback (#1593). I've copied in
this message to Feedback as well.
It's important to note that the (defective) behaviour is consistent
regardless of whether you start by CLEARing LIST2 or LIST1 or any other
pointer to the same (unnamed) series. So, it's not an exception, it's a
bug (that proves the rule).
*********** REPLY SEPARATOR ***********
On 12/12/1999 at 12:19 PM [EMAIL PROTECTED] wrote:
At 11:24 AM 12/12/99 -0700, you wrote:
>
> Howdy, Ted. You said:
>
>> Every series is a movie, and all the variables only frames.
>
>
> Wow. You may never know just how right on the money the above
>statement is! It is a very good analogy. In fact, in the same sense,
>all of REBOL is a movie, and all variables are frames of the big REBOL
>movie. :-)
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
1. Assigning next list to list2 was legal at the time the assignment
was made.
2. Subsequently clearing list was legal at the time list was cleared
3. Asking for the length of list2 is legal at the time length? is being
evaluated. 4. The evaluation of a sequence of legal expressions should
not
lead to an error message!
5. Instead the returned length should be 0, -1 or none. (-1 would
indicate
that list2's offset into the list is greater by one than the length of
the
block it references. None would indicate that list2's offset does not
warrent a sensible answer).
Look here:
>> insert list [1 2 3 4]
== []
>> list2
== [2 3 4]
>> length? list2
== 3
It should be possible to modify the block list2 points to and continue
to
use list2 as a pointer into the the block it references beginning at
offset
2. In order for this to work seamlessly, the case in which the block
has
been modified such that an offset of 2 or more is no longer legal for
the
block being referenced must be handled correctly.
I believe that the "cheapest" way for handling it correctly is to have
every word that references a series negotiate the legality of its
offset
before it attempts to access the series at that offset and it should
report
some indication that its offset into the series is illegal whenever
that is
the case.
2 cents-ibly,
Elan
