[REBOL] Re: Core 2.5.5 Beta Versions
From: joel:neely:fedex at: 24-Feb-2003 5:44
Hi, Gabriele,
A slightly different POV...
Gabriele Santilli wrote:
> On the contrary, I think it would be very easy to implement.
> I just think the interpreter should reset out-of-range series
> values to the series tail when they are evaluated.
>
Horrors! 8-0
I think we'd be much better served by having INDEX? simply tell
us the index of a series under all circumstances (whether in
range or not). A script could then easily determine in advance
whether a series ref was "safe" to use or not, without having
an error thrown. In this approach, your hypothetical example
would appear as...
> a: "12345"
> b: skip a 2
> clear a ; nothing happens to b here
> index? b ; == 3 (KEEPS its position attribute)
...at which point one could evaluate
index? b > length? head b ; == true
... to see that it isn't currently "safe" to access via b, then ...
> insert a "12345"
> index? b ; == 3 (STILL at the same position)
>
...at which point
b ; == "345" (at same position over new data)
> This way it would be like if out-of-range series did not
> exist at all; I think it would be much less confusing
> (as out-of-range series are not useful, so I don't need
> that concept in the language).
>
If the interpreter handled every attempt to access an undefined
word by changing the word reference to some other (defined) word
in SYSTEM/WORDS, then we'd never get errors caused by UNSET!
either. I think unset words are not useful, so i don't need that
concept in the language. ;-)
Seriously, I *strongly* dislike having the language change things
behind our backs, instead of just giving us a straightforward way
to look at the actual situation and make our own decisions.
In the following transcript:
>> a: "1234567" ; == "1234567"
>> b: at a 4 ; == "4567"
>> clear at a 3 ; == ""
>> a ; == "12"
>> append a "CDEFG" ; == "12CDEFG"
>> b ; == "DEFG"
the position of B is *temporarily* out of bounds while the string
in A is being massaged. At the completion of that massaging,
however, B now provides access to what is at the corresponding
position in the new data. That seems useful to me.
To illustrate...
Suppose I have a source of data providing fixed-format lines
(or groups of lines) sepearated by empty/blank lines:
HOST TIME STAT USERS CPU
197.168.0.1 23:45:00 Up 13 27%
197.168.100.23 23:45:01 Up 5 11%
197.168.101.2 23:45:01 Down 0 0%
197.168.0.1 23:50:00 Up 15 45%
197.168.100.23 23:50:01 Up 7 23%
197.168.101.2 23:50:01 Up 4 70%
... and so on. Now imagine the behavior of the following fragment
if we were allowed to examine INDEX? as I recommend:
a: first-log-line
b: find a "STAT"
forever [
a: next-log-line
if length? a >= index? b [
print b
]
]
We'd get output containing (well, beginning with -- adding the
code to break off at the first blank or end of string would have
bulked up the example) the STATus field for every line coming
from the data source. B is keeping up with which part of A we
need to look at (for every A that has that much data).
I'm certainly not saying that this is the only (or even best)
way to write this little fragment, but just trying to illustrate
that knowing where you were in a series (or being able to look
at that same place again) is a useful concept, regardless of how
the data in the series may change.
-jn-
