[REBOL] Re: Core 2.5.5 Beta Versions
From: joel:neely:fedex at: 21-Feb-2003 16:41
Hi, Romano,
Romano Paolo Tenca wrote:
> It don't see an easy solution for this problem.
>
We could make it easier if we tackle a larger problem!
(see below ;-)
> When one remove a series value, the interpreter should check if
> any other relative series is now out-of-range and correct the
> index value to make it equal to the new tail, but this is a time
> consuming task.
>
I don't agree that it "should", but do agree that it is infeasible
(especially with the insertion of the word "too", which you did
a few sentences later ;-).
But there's a bigger issue anyway. We have multiple cases of REBOL
expressions that we'd think would mean/do the same thing, but which
do not. For example, let's set up with this:
>> a: "abcdefg" == "abcdefg"
>> b: back tail a == "g"
>> c: index? b == 7
>> first at a index? b == #"g"
>> first at a c == #"g"
>> pick at a index? b 1 == #"g"
>> pick at a c 1 == #"g"
Note that the last four expressions yield identical values. Now
let's start down the slippery slope:
>> clear at a 5
== ""
>> a
== "abcd"
and find that (with 1.2.1.3.1) lots of things break...
>> length? b
** Script Error: Out of range or past end
** Where: halt-view
** Near: length? b
>> index? b
** Script Error: Out of range or past end
** Where: halt-view
** Near: index? b
>> first at a index? b
** Script Error: Out of range or past end
** Where: halt-view
** Near: first at a index? b
>> pick at a index? b 1
** Script Error: Out of range or past end
** Where: halt-view
** Near: pick at a index? b
but note this contrast!!!
>> first at a c
** Script Error: Out of range or past end
** Where: halt-view
** Near: first at a c
>> pick at a c 1
== none
Why should PICK _ 1 behave differently than FIRST _ in any
situation?
> How to resolve this situation of confusion between out-of-range
> series and tail series?
>
I suggest that the following behavior for series values is simple,
and also makes sense (not always the same! ;-)
- INDEX? should *always* return the "position" of the series,
regardless of the number of values in the underlying sequence.
- Content access (whether directly via that series ref, or using
AT , SKIP , BACK , NEXT , etc. relative to current position)
should *always* return NONE if the reference (or relative
position after adjustment) is out-of-bounds, or should
*always* return actual data if the reference (or relative
position after adjustment) is within bounds.
In this view, given something like this:
a: "ABCDEFGHI"
b: at a 5 ; i.e., assuming a is at head
index arithmetic
such as
index? b ; ==> should be 5
index? back back b ; ==> should be 3
would always evaulate consistently, even if something like
clear next a
intervened. Additionally, the role of NONE would become more
standardized, so that (just as SELECT and FIND simply return NONE to
indicate that the requested value is unavailable) the previous five
expressions would leave us in a state where
first b
would simply evaluate to NONE instead of throwing an error, in much
the same way that
>> pick "?" 3
== none
behaves nicely (and, as we all know, the apparently equivalent
>> third "?"
** Script Error: Out of range or past end
** Where: halt-view
** Near: third "?"
does not!)
Any thoughts on that?
-jn-
--
----------------------------------------------------------------------
Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446
Counting lines of code is to software development as
counting bricks is to urban development.