Mailing List Archive: 49091 messages

# Indices Of Series

### [1/1] from: lmecir::mbox::vol::cz at: 16-Feb-2003 14:35

Hi, I have added this to my REP. My POV in this case may be well known to some, but it haven't been presented completely yet. Here it is: ===Indices Of Series ---A SKIP Trap The NEXT function isn't linear in the following sense: for any series S the expression next tail s yields the same result as the expression tail s This breaks a symmetry, because in all other cases the NEXT function creates a series with different index, than the index of its argument. The same holds for the BACK function at the head of a series and for the SKIP function at both ends. Although this behaviour looks reasonable, it is the cause of two bugs in the mezzanine function FOR. If even the implementor of the language gets "caught" by a feature, then the feature should be reconsidered. ---Big Skips The INDEX? function gives us useful information about series, although sometimes it works as follows: a: "11" b: next a clear a index? b ; ** Script Error: Out of range or past end ; ** Near: index? b It looks (at a first glance), that there is nothing wrong with this approach, because the "large indices" may be considered "illegal". Nevertheless, the big skip occurred before we used the INDEX? function, i.e. the function cannot help us to eliminate it as a possible error. ---MINDEX? It is compatible with the language to define a new function able to yield a meaningful index value for any series: mindex?: function [ {always return a meaningful index value} series [series!] ] [orig-tail result] [ if error? try [result: index? :series] [ orig-tail: tail :series insert :orig-tail #"1" while [error? try [result: index? :series]] [ insert tail :series head :series ] clear :orig-tail ] result ] Test: a: "11" b: next a clear a mindex? b ; == 2 The only trouble with the MINDEX? function is, that its non-native implementation is too expensive, that is why it should be implemented natively instead (e.g. as a refinement of the INDEX? function) ---PICK Hole If I am able to pick a value at the position I in a series and a value at the position I - 2 in the same series, I would expect, that I am able to pick a value at the position I - 1 too. That isn't true, if I is equal to 1. This is a similar trap as above, although I haven't seen many bugs caused by overlooking it. It would be good to have a native function able to work more consistently. ---PICK deficiency Let's look at the code: a: "123456789" b: skip a 8 pick b -8 ; == #"1" Now let's suppose, that we do: clear skip a 6 pick b -8 This is not acceptable, because the correct answer hasn't changed (at least for me). Again, a native function working more consistently would be better. ---Negative Big Skips I do not see any reasons, why we couldn't have a function able to create series with negative indices exactly like we (can) have a function creating series with big positive indices.