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: 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.