Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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) 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) > 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 23:45:00 Up 13 27% 23:45:01 Up 5 11% 23:45:01 Down 0 0% 23:50:00 Up 15 45% 23:50:01 Up 7 23% 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-