> Maybe so. It's sad an extra layer of logic has to be added across
the board to deal with outlying cases.
If my understanding of how REBOL works is correct, it's not a matter of
an extra layer of logic. The current layer of logic is simply
defective. I don't believe that the seminal variable actually owns the
block, and so all pointers to the block should be able to tell when the
block has been truncated, and robustly return NONE. This is the
documented behaviour. IMHO, I don't believe the developers would want
us to quietly "make do" and workaround this early in the game. And,
it's very possible that once the code is fixed, the documentated
behaviour will not degrade performance (because this is how REBOL was
designed to work). Heck, fior all we know, the bug and it's
side-effects could be slowing things down.
>So I would vote to change the meaning of empty? to head tail?
I think that's why there is a synomyn ">> head tail?" just sounds
topsy-turvey.
Though, empty? being a snyomyn for "head tail? would be consistent with
the way append works, which is basically the same as "insert tail".
> If I reverse the example, clearing list2 instead of list, I get the
correct behavior:
>> list: [1 2 3 4]
== [1 2 3 4]
>> list2: next list
== [2 3 4]
>> clear list2
== []
>> list2
== []
>> list
== [1]
In this example list is still at the head. The bug doesn't occur when
the other variable is at the head or the tail. Try
>> list: [1 2 3 4]
== [1 2 3 4]
>> list2: HEAD list
== [1 2 3 4]
>> list: NEXT list
== [2 3 4]
...
-Ted.
