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.