AltME groups: search

http://www.youtube.com/watch?v=UzdT9s-CfdE&list=PL2736E5F6878491D9&index=5&feature=plpp_video

Oh, with path notation, you need to adjust the loop to start counting 
the index from 1

Did you installed the Rebol plug-in in your browser? Look at  http://www.maxvessi.net/rebsite/plugin/index.html

Nenad, can you give me an example, please? When the function requires 
for example (pseudo-code):
     pointer! [byte!] integer64! struct! ; data, index, metadata
how should I pass the integer64! value?

There is a bit that is worth learning from R3's Unicode transition 
that would help Red.


First, make sure that strings are logically series of codepoints. 
Don't expose the internal structure of strings to code that uses 
them. Different underlying platforms do their Unicode APIs using 
different formats, so on different platforms you might need to implement 
strings differently. You don't want these differences affecting the 
Red code that uses these strings.


Don't have direct equivalence between binary! and string! - require 
conversion between them. No AS-STRING and AS-BINARY functions. Don't 
export the underlying binary data. If you do, the code that uses 
strings would come to depend on a particular underlying format, and 
would then break on platforms where the underlying format is different. 
Also, if you provide access to the underlying binary data to Red 
code, you have to assume that the format of that data can be corrupted 
at any moment, so you'll have to add a lot of verification code, 
and your compiler won't be able to get rid of it.


Work in codepoints, not characters. Unicode characters are complicated 
and can involve multiple codepoints, or not, but until you display 
it none of that matters.


R3 uses fixed-length encodings of strings internally in order to 
speed things up, but that can cause problems when running on underlying 
platforms that use variable-length encodings in their APIs, like 
Linux (UTF-8) and Windows/Java/.NET/OSX? (UTF-16). This makes sense 
for R3 because the underlying code is compiled, but the outer code 
is not, and there's no way to break that barrier. With Red the string 
API could be logical, with the optimizer making the distinction go 
away, so you might be able to get away with using variable-length 
encodings internally if that makes sense to you. Length and index 
would be slower, but there'd be less overhead when calling external 
API functions, so make the tradeoff that works best for you.

https://bitcointalk.org/index.php?PHPSESSID=4d5de9b6d61b4f35e349320621804bcb&topic=93386.0

All I know is here: http://www.sqlite.org/src4/doc/trunk/www/index.wiki

Oh, the particular quality of the R3 extension dispatch model that 
makes it well-suited to JIT compiler implementation is that a command 
function contains an indirect reference to the dispatch function, 
and an index integer. When the command is called, the runtime calls 
the dispatch function and passes the integer and a marshalled stack 
frame. For a JIT compiler dispatch function, the index of the command 
can be an index into an array of function pointers or something like 
that, and the dispatch function can just pass the stack frame to 
the appropriate function, then return the results. This means that 
the hard part of JIT compiling - getting the regular runtime to call 
the created functions - is something that you essentially get for 
free with the existing command mechanism.


You could also use the dispatch function to marshall arguments into 
another runtime with a different call model. You could, for instance, 
have a dispatch function that pushes the contents of a marshalled 
stack frame onto a Lua stack and calls Lua functions. Or you could 
do something similar for LLVM functions, or ActiveScripting languages, 
or V8, or ODBC queries, or even Red's JIT.


This all depends on having a good marshalling model in the first 
place that can handle the datatypes you need to support, and it would 
also help if there was a good task-safe callback mechanism that actually 
works (R3's needs a bit of work at the moment). Still, the principle 
is sound.

http://www.youtube.com/watch?v=9eQPtrw8rIQ&list=PLN-OHO8jjoowvi5peIoOp_E05wpf2YQVh&index=1&feature=plpp_video

I agree that we should have only _one_ convention, else it will quickly 
become a nightmare when having to integrate 3rd-party code. We need 
to find some objective reasons for choosing it. 


For Red, I'm inclined to continue on the one-based convention that 
worked pretty well in R2 for many years (at least for me). I'm not 
very fond of the change in R3, introducing 0-based convention implicitly, 
it solves one problem (iterating over 0 index...I don't remember 
ever doing that), but introduces new ones (negative indexes point 
now to an IMHO, counter-intuitive position which will most probably 
lead to programming errors). For now, I prefer to stick to R2 way, 
until  we find a better solution (feel free to propose some on related 
github tickets or here). For example, we could decide to ban indexes 
<= 0 (not my favorite personal option though, but would solve simply 
the problem).


For Red/System, a 0-based convention might make more sense, but it 
would push us into the R3 issue I've mentioned above wrt indexes 
<= 0. Also, as a dialect of Red, it can use whatever convention best 
fits its purpose, but OTOH, having the same convention as Red would 
help. So, I'm really undecided for Red/System.


I think the whole issue boils down to decide about PICK behavior 
with <= 0 indexes, everything else should be able to fit in easily 
once that preliminary question is solved. It would be helpful if 
someone could put up everything related to this topic on a wiki page 
with all arguments sorted (there's a lot of them in R3 group posted 
a few weeks ago).

As for R3, it did not really introduce "0-based convention implicitly", 
it still is firmly "1-based" in as far as the first element in a 
series can be accessed using index 1.


When you want indices-as-ordinals, you really need to decide: (a) 
is the ordinal "zeroth" meaningful, and if so, what it means; (b) 
are negative indices meaningful, and if so, what they mean.


R3 went with the choices of (a) having meaningful zeroth, defined 
as "the item in a series before the first item", and (b) allowing 
negative indices, having index -1 as the immediate predecessor of 
index 0.


R2 went with the choice of (a) not having a meaningful zeroth, but 
instead of erroring out, functions (pick) & syntax (paths) accepting 
indices are lenient: passing an index of 0 always returns NONE. For 
(b), R2 allows negative indices and defines -1 as the immediate predecessor 
of 1.

Andreas: thanks for the good sum up.


R3: agreed that index 1 is still the first element in a series, but 
index 0 is allowed and there is this ticket #613 that clearly aims 
at introducing 0-based indexing in R3...so my guessing was these 
different changes or wishes were inter-related. http://curecode.org/rebol3/ticket.rsp?id=613


R2: I would have really prefered that index 0 raises an error than 
returning none.

If you wish to allow index computation for series not positioned 
at the head, allowing index 0 is actually quite sensible, unless 
you want to make index computation particularly error prone.

The problem with no meaningful index 0 is that potentially meaningful 
index values are no longer isomorphic to integers. And as REBOL has 
no actual datatype for indices, all we can compute with are integers 
while relying on a correspondence of those integers to indices.


If you only ever compute indices for series positioned at the head, 
you get a nice correspondence of integers to indices, because meaningful 
indices for this series correspond to the positive integers.


But if you also want to compute indices for series positioned elsewhere, 
this nice integer-to-index correspondence breaks down as you suddenly 
have an undefined "gap" for the integer 0, whereas negative integers 
and positive integers are fine.

Andreas: do you have a short code example involving index 0 in computation? 
I don't remember ever having issues with index 0 and I use series 
with offsets a lot! Though, Ladislav claims he and Carl did encounter 
such issue at least once...the use cases for this issues remain a 
mystery well kept by Ladislav. ;-)

Ladislav: I think it is relevant to this topic as findind out if 
the index 0 gap is a real practical issue or not, could help decide 
about the indexing base.

tail position

 is actually a misnomer, in as far as it corresponds to no proper 
 index of a series. The special behaviour series seen in some functions 
 when operating on series in "tail position" would warrant "tail mode" 
 as a more sensible description of the state the series is in.

as it corresponds to no proper index of a series

 - I reserve the right to disagree. INDEX? TAIL gives some correspondence

Yes, it gives an index that can I'd consider "improper" for the series, 
in as far as the series does not contain a value at that position.

(And an index that does not correspond to a value in the series, 
at this point in time.)

In the light of these, taking the INDEX? help string we may actually 
say that the formulation:

Returns the index number of the current position in the series.

is actually indefinite, not determining anything at all

My thought behind the "tail position" complaint above was, that series, 
position, and index are already used rather exchangably, and lax 
in a few parts of REBOL's documentation. Adding "tail position" to 
the mix, only further contributes to that confusion.

If you realize that indices are one degree vectors.   A lot of this 
discussion becomes moot.   vectors of length 0 are considered impossible 
when considering only natural numbers (due to 0 divide).  This is 
why I consider R2's handling of indices proper.   


As such, any series "position" is not AT a value it is LOOKING AT 
a value (oriented in positive direction, starting at a point in space 
which is "0").   like extending your arm to grasp the nth thing in 
front of you.  


Tail are 0 length vectors (thus mathematically imposible), when we 
are beyond  the last item edge we are at the edge of space.   you 
cannot "take" the tail item, there is nothin in front of you, just 
as you cannot "take" the 0th item, there is no such thing, 0 is the 
origin of the vector).


when we consider series indices to be vectors, we see the natural 
relationship which Ladislav pointed with SKIP and other methods.


with vectors, things like COPY/PART make sense in the negative direction, 
just as well as in the positive direction.



In R3, this was changed to indices being OVER a value , with the 
first item requiring you to look down and then away for other values. 
 The issue is that index 0 is looking backwards... that doesn' map 
to any good reasoning.  In fact it creates many weird inconsitencies 
in the model, when you try to describe it.


R3's series changes seem like a kludge work-around to map non-vectorial 
infinite integer space to a bounded vectorial space. sacrificing 
model integrity in the process (while trying to ease its mathematical 
properties).  R3's series *may* be "easier to count in a loop"  but 
the values being used make no sense.   counting backwards requires 
us to manipulate the indice for it to "make sense", whereas before, 
counting backwards was the same as counting forward.  we where just 
LOOKING in the opposite direction (the vector's orientation is inversed).

The issue is that index 0 is looking backwards... that doesn' map 
to any good reasoning.  In fact it creates many weird inconsitencies 
in the model, when you try to describe it.

 - it may not be a "weird inconsistency", but it is almost imposible 
 to describe to a newbie in a reasonable way

I somehow incline to R2's behaviour just with error instead of none 
for 0's index

You do not necessarily have to iterate over the series. I look up 
some values in a table and retrieve or store data at that index of 
a series.

But than again I use subscripting b/(i) over 'pick, maybe I must 
go back to REBOL School  ;-)

Maybe, but we still have the 0 index issue, `series/0`giving you 
access to item before current series position is IMO highly confusing.

Just erroring out on index 0 is ann improvement.

Making "pick 1" and "pick -1" return the same element is an improvement.
R3's behaviour is an improvement.

R2's messy behaviour with a clean set of SKIP, PICKZ, POKEZ is an 
improvement.

Just erroring out on index 0 is ann improvement.

 That's my intention for Red until we get a consensus on a better 
 overall solution.

You can stay at the beginning of the series if you add the base offset 
to every calculated index reference. Bad idea in REBOL, too slow, 
but maybe Red's optimizer will be smart enough to undo that calculation. 
How many algebraic transformations will the optimizer be able to 
handle?

For that matter, in R3 (where I don't get caught by the 0 hole for 
PICK/POKE, just for AT) I have to do an offset-forward-by-one reference 
to avoid having to add 1 to every calculated index reference. Doesn't 
help in R2 though.

Most computed index situations use modulus, which generates 0-based 
numbers. If there's no 0 hole in PICK/POKE then you can do PICK/POKE 
NEXT, as long as this doesn't have side effects the way it does for 
port schemes or weird copy-on-write stuff; in that case PICKZ/POKEZ 
would be more of a convenience. If there's a 0 hole in PICK/POKE, 
you absolutely need a version of the functions without that hole, 
and having the extra advantage of being 0-based would be even better, 
an extra justification for their existence.

(sorry, there's two standard ways to pluralize index and I don't 
use either consistently)

I thought they only did the negative and zero index.

As someone who is at say level 5 on the btiffin rebol scale what 
I am about to suggest may be stupid - if so be gentle :) Could we 
not create a different structure other than a series (an array or 
a matrix etc) that is 0 based and index driven and works like in 
most other languages for those who need that kind of usage?  Or could 
we introduce for series an index manipulation system such as this:s1/index: 
4, add s3/index 2, subtract s2/index 2, inc s3/index, dec s2/index, 
++ s1/index, s1/index: s1/index + off etc.

No, because at least for me, this is very common usage (just with 
different names):
>> b: [index 2 foo 3]
== [index 2 foo 3]
>> b/index
== 2

At least triggering an error is easier to explain, it means that 
0 doesn't exist, like we're programming in Roman. It's (slightly) 
better than the 0 index existing but referring to a hole in the series 
(R2-style behavior).

why 1 would be a better starting index than zero? Why not 2, or 10? 
The answer itself is interesting because it shows a lot about the 
though process of the people defending the idea.

 - what an flawed argument - the guy completly missess language as 
 REBOL imo, where we have first, second, etc. And first simply returns 
 first real thing. What is zeroth thing?

Well, really difficult to settle, any way you think abou the topic. 
I can think about 0 as about in-between, non real value - like Max 
mentioned vectors, simply first element in series to the left, or 
to the right. Then I can think about 0 as about real value - if I 
look outside, there is -1C temperature. And in order to get to 1C 
temperature, 2 grades are needed, hence 0 is real value here. And 
finally - if I will have some real series in front of me, e.g. 10 
ppl, I can pick first, second, first to the right, first to the left 
(-1), hence no zero or negative index here ...

Default base index in programming languages: 

http://en.wikipedia.org/wiki/Comparison_of_programming_languages_%28array%29#Array%5Fsystem%5Fcross-reference%5Flist


Notable languages with 1-based indexing: FORTRAN, Lua, Mathematica, 
MATLAB, Smalltalk.

Ada and VHDL/Verilog are two other languages that spring to mind, 
which allow choosing the index range, like Pascal.

I feel that there is a consitent way to look at 1-based relative 
addressing but only if you consider 0 to be the position immediately 
before the current position.


It is to define the given index as an offset from 1 (the current 
position). (Examples using current position as absolute index 5 [1-based])


index 10 would be calculated as offset 9 positions from the current 
position [absolute 14]

index 1 would be calculated as offset 0 from the current position 
[absolute 5]
index 0 wold be offest -1 from the current position [absolute 4]

index -1 would be offset - 2 from the current position [absolute 
3]


I know that most people will see this as a kludge or don't like it's 
different behaviour to REBOL2.

Seeing as the use cases for accessing elements before the 'HEAD appears 
to be quite rare, couldn't pick-back be left as a "mezzanine":

pick-back: func [ser index] [pick skip ser negate index 1]

My Understanding of Series:

A contiguous collection of boxes sequentially numbered in ascending 
order starting at 1.
Each box can contain any rebol value
The head of a series is always box number 1

The last item in a series is always in box number (length? series)
The tail of a series is always box number (length? series) + 1

Any series can have multiple words referencing any box in that series 
resulting in a sub-series (but not a copy)

index? series - always returns the box number of the value referenced 
by series

Evaluating a word referencing a series returns the series from box 
number (index? series) up to and including box number (index? tail 
series)

index? is the only rebol word that directly uses the box numbers 
of the series

All other rebol words that manipulate series are relative to the 
box number of the word referencing the series

A series is empty when: equal? head series tail series => true – 
or – when all boxes are empty

Examples:

s1: [a b c d e f g h i j]  => creates 10 boxes numbered 1 to 10 from 
the left with a in box 1 and j in box 10 – unseen is box 11 which 
is 'tail as seen by: index? tail s1

s2: at s1 3 => references s1 starting from box 3 of s1 - [c d e f 
g h i j]

s3: at s2 4 => references s1 starting from box 6 of s1 - [f g h i 
j] which is item 4 of s2

probe index? s1 => 1
probe index? s2 => 3
probe index? s3 => 6


probe head s3 => [a b c d e f g h i j] - showing that s3 references 
the same series as s1

probe pick s1 2 => 'b
probe pick s2 2 => 'd
probe pick s3 2 => 'g


probe s3/-2 - this is shorthand for back back s3 or pick s3 -2 (the 
negative number simply means move back twice) => 'd

probe tail s1 => []
probe tail s2 => []
probe tail s3 => []

forall s2 [prin first s2] print => cdefghij
forall s3 [prin first s3] print => fghij

probe index? tail s1 => 11

Possible SOLUTION:

So, what is missing? Words that directly manipulate the box numbers 
(index)? – so maybe we need something like this:

s1/index: 4 => sets the index of s1 to 4 and causes word s1 to reference 
the series starting from box 4

add s3/index 2 => adds 2 to the index of s3 causing s3 to reference 
the box 2 places further on => 'h

add s2/index -2 or subtract s2/index 2 => subtracts two from s2's 
index causing s2 to now reference box 1

You can now use any mathematical operations on the index of a word 
referencing a series as long as it results in an integer in range

If index? series > (length? series) + 1  or index? series < 1 then 
an "index out of bounds" error should result
Zero is a non-issue because it has no meaning in a 1 based series

This kind of shorthand: s1/-3 becomes redundant - but if kept still 
means: back back back s1

I honestly think there is so much confusion over this because we 
are trying to merge together two different "concepts". Concept 1 
is a series which is traversed as in Rebol 2 and whre s/-2 is shorthand 
for back back s. Concept 2 is a 0 based sequence which is traversed 
via index manipulation. The concepts need to be kept seperate even 
if they are applied to the same set of contiguous boxes. The only 
way to do this as far as i can see is to develop a set of index manipulation 
functions in addition to the existing series traversal functions. 
The concepts can then be easily taught to newbies and gurus can mix 
and match to their hearts content.

There is no 0 by convention - that is what defines the "concept" 
of  series traversal. Arrays are traversed by index manipulation 
whether 0 based or not..

Concept 2 is a 0 based sequence which is traversed via index manipulation.

That interpretation doesn't match `FIRST s` and `PICK s 1`...

Yes but Frst s and Pick s 1 are series functions - not index manipulation 
functions - different concepts - first s in index system would be 
s[i]

the 1 in `pick s 1` sure awfully looks like an index to me :)

The 1 in Pick s 1 is not an index it is an offset from s

In an index system if you want box 4 you say s[4] - or if your current 
index is at 1 and you want box 4 you say s[i + 3]

Andreas - the problem I have with ordinals is how do you do mathematics 
on them eg. 3 + -3rd ? Index manipulation uses ingteger! and so is 
mathematically modifiable

It's just a dialect for going in the opposite direction

 - it is not, in fact. (PICK SERIES INDEX) is just an evaluation of 
 a function, not a "dialect"

Now, try to come up with a way to explain to newbies that this phantom 
hole in a series makes sense, or is a good idea.

 - yes, a good illustration from a beginner/documentation/education 
 POV. Also, what is exactly as bad even for experienced users is that 
 it disrespects arithmetic making simple index arithmetic (ADD INDEX 
 OFFSET) not usable.

It's just a dialect for going in the opposite direction" - it is 
not, in fact. (PICK SERIES INDEX) is just an evaluation of a function, 
not a "dialect""

False. PICK SERIES INDEX is usually evaluated as DO dialect. It could 
also be evaluated as any other dialect

Also, what is exactly as bad even for experienced users is that it 
disrespects arithmetic making simple index arithmetic (ADD INDEX 
OFFSET) not usable.


I guess you're not talking about R2, which index arithmetic has proven 
to be very usable in last twelve years (at least) through countless 
*working* user apps.

I guess you're not talking about R2, which index arithmetic has proven 
to be very usable in last twelve years (at least) through countless 
*working* user apps.

 - "working" are only the ones limiting the index arihmetic to some 
 special cases. Those not limiting themselves to such cases are not 
 working.

Here is a task I consider relevant:


1) define a function obtaining a series S and an index I and yielding 
an index J such that PICK S I would be equivalent to PICK HEAD S 
J
1a) do the task in R2
1b) do the task in R3
1c) do the task in R4 with zero-based indexing

This is my solution of 1c):

head-index?: func [s [series!] i [integer!]] [i + index? s]

(that is what I call "working index arithmetic")

This is my solution of 1b):

head-index?: func [s [series!] i [integer!]] [i - 1 + index? s]

(again, a case of "working index arithmetic")

...and also for people stating that "index arithmetic *is* working 
in R2"

I know this would be consiidered a "workaround" but

head-index?: func [s i] [i - (index? head s) + (index? s)]

Testing your implementation with:

1 = index? head s
0 = i
2 = index? s

i get:

1 = head-index? s i

, which is incorrect

Well, I would state that my task looks like a "simple enough task 
to tackle", and the one even inexperienced users (surely not only 
mathematicians) should be able to tackle, and they would, as Peter 
demonstrated, if the index arithmetic weren't broken.

Which means that either Doc prefers path syntax over function syntax, 
or path syntax was implemented first, or both. Nonetheless, it's 
real code of any significant complexity, so it probably includes 
backward index use.

Just to make myself more clear for "common people": I think that 
the programming language should be designed so that "common people" 
should not need a specialized mathematical training to be able to 
define the HEAD-INDEX? function; rather I think that they should 
be able to successfully tackle a problem of such a low complexity 
without any problem. Also, I noticed that Kaj's opinion differs.

If I'm given PICKZ and POKEZ, I couldn't care less about the poor 
souls suffering from trying to use path syntax with negative indices

 - if I know you well, you would actually explain to them the advantages 
 of the simple approach (especially when being asked about some index 
 arithmetic problem), and I am sure that the "reasonable souls" would 
 join you soon, and the others would either stop programming in the 
 language or follow suit as well.

head-index?: func [s [series!] i [integer!]] [case [i < 0 [i - index? 
s] i > 0 [i - 1 + index? s]]]


This should also return none if i is 0, which replicates the hole.

Wait, it's supposed to return the index, not the result.

head-index?: func [s [series!] i [integer!]] [case [i < 0 [i - index? 
s] i > 0 [i - 1 + index? s] i = 0 [0]]]

Welcome to R2 index arithmetic :-/

Yes, Brian is right, that is R2 index "arithmetic", the only problem 
is that CASE is not "arithmetic", as you might have guessed.

Ladislav, thanks for bringing a tangible example that demonstrates 
our both points. I will try to be brief:


1) I will start by repeating again that nobody contests that having 
a continuous numbering is better than a discontinuous one (for pure 
arithmetic efficiency, as you've showed).


2) Brian showed that R2 is not "broken" as the head-index? function 
can be written. 


3) I have never needed to write such "workaround" in R2, nor did 
I remember seeing it in others code (if someone did use such workaround, 
please step in, we need real-world use-cases).


4) According to 3), I think the issue you are showing with head-index? 
function covers extremely rare use-cases. 


5) I often use series with an offset and I do index computation on 
them, but usually, in a single direction at a time (using only positive 
*or* negative indexes). In the very rare cases where I need an index 
computation "over 0", I switch to absolute (from head) indexing, 
but not relying only on index arithmetic, but also on series navigation 
using the INDEX? SKIP idiom. This short idiom gives exactly what 
your head-index? function gives to you, but using series navigation 
abilities rather than pure index arithmetic. Of course, it works 
because SKIP is an implicit 0-based system with no hole.


6) INDEX? SKIP in R2 solves the "hole issue", for the very rare cases 
where we need to solve it. So, allow me now to propose my own head-index? 
implementation:

    head-index?: func [s [series!] i [integer!]][index? skip s i]


It is not pure arithmetic for sure, but we are programmers, not mathematicians 
(except you who is both :-)), so this solution is IMHO as acceptable 
as pure arithmetic ones, from a programmer's point of view.


So, what I contest is the trade-off required for "fixing" index arithmetic 
in R3, resulting in IMHO "broken" PICK and path notation for 0 and 
negative indexes. Also, given that INDEX? SKIP is available in R2, 
the "fixing" seems even less necessary. Still, I am open to discussing 
options for improving index arithmetic but *without* having to break 
other features.


I think we will agree to disagree about the right trade-offs between 
R2 and R3.


So, can we now all focus on studying the different improvements proposed?

Brian showed that R2 is not 

broken" as the head-index? function can be written." - Carl demonstrated 
(on his own bug) that it *is* broken, and what is broken is not "R2", 
what is broken is the index arithmetic, as Brian's example clearly 
demonstrates (you need to use CASE, index arithmetic cannot be used).

According to 3), I think the issue you are showing with head-index? 
function covers extremely rare use-cases.

 - as opposed to that, my opinion is that the HEAD-INDEX? function 
 represent an, "extremely simple" use case that everyone should be 
 able to solve without having a specialized training to be able to 
 do so.

For example, when traversing two series at the same time while using 
just one index variable (which is pretty common), you need to be 
able to use the variable to correctly point to the corresponding 
places in both series, which logically *needs* some version of "index 
arithmetic".

head-index?: func [s [series!] i [integer!]][index? skip s i]

 - however, this does not do what was requested, the number obtained 
 does not have the required property!

'So, what I contest is the trade-off required for "fixing" index 
arithmetic in R3, resulting in IMHO "broken" PICK' - this is the 
main point, as I see it. If I remember well, you consider PICK broken 
since "0 points (maybe unnaturally for you?) backwards for PICK"? 
If that is what you dislike, then I can sympathize, having similar 
feelings:


It is necessary to realize what PICK SERIES INDEX is supposed to 
do. In my opinion it is a "relative operation" (relative to the current 
series "index" - having two series with common head but different 
"indices" we expect the PICK function to yield different results). 
Us such, we need to realize that we already have a "relative operation" 
for series for quite some time, which nobody contests to be "relative" 
- it is the SKIP operation. So, we have SKIP SERIES I being relative 
and we should have a natural obtain-value-of SKIP SERIES I shortcut 
instead of the whole nonsense, which is what you instinctively do 
presenting your (in R2 wrong!) HEAD-INDEX?.

Still, you're lucky thet you haven't been caught by this.
 - actually, he has been, just above he wrote:

    head-index?: func [s [series!] i [integer!]][index? skip s i]

, which caught him completely

head-index?: func [s [series!] i [integer!]] [index? at s i]

http://www.youtube.com/watch?v=YtLHl-Kpyyg&list=PLo1XY7fgXbYZkC5H38c7UhlVVHWz2gztd&index=1&feature=plpp_video

Where are all these tutorial? The problem is reaching tutorial pages. 
It''s all spread around the world, without an index.

Look at this pages http://www.maxvessi.net/pmwiki/pmwiki.php?n=Main.GuidaARebol
   http://rebol2.blogspot.comhttp://http://www.maxvessi.net/rebsite/wr/ 
        I try to unify all documentation, but it's missing a central 
index.

http://lang-index.sourceforge.net

Chris -- a couple of articles about experience in retrofitting R2 
scripts to run as R3:
   http://www.rebol.org/art-display-index.r?a=R3

Yes, that would be a good reason. In my patches to port Python, for 
example, I solve it by looking if the /system/index/ directory exists, 
which would identify not only Syllable Desktop, but also Syllable 
Server

Kaj, thanks for all your hard work. When I click on http://red.esperconsultancy.nl/index.red
I see the actual code. Is it suppose to behave that way?

Well I found a more promising way here http://www.codeconscious.com/rebol/view-notes.html
What I want to do is have a number of text/labels that I want to 
show a short text from a block of values. So I prefer to do it in 
a loop like loop 8 [mylabel/index/text: myblock/index]

but if you need to sort with sf above (which uses obj data) then 
you also need to add the index within the skip. (because the obj 
is not the first item of the fields marked with /skip

so it would be:
sort/compare/skip/index series :sf 2 2

compare is used for the index and the func... hum.

The "in some cases faster" depends on whether you're going in reverse, 
and how much data you have. REVERSE can have a lot of overhead if 
you have a lot of data, so with enough data it would be faster to 
just work in reverse using a WHILE loop, or possibly better yet a 
REPEAT with an index that you subtract.

map-each [x: y] [...] is an interesting use. I sometimes needed to 
get that "index" value but I didn't know that usage so I used forall 
instead. Good to learn.

http://linuxnetworks.de/doc/index.php/OpenDBX/DBMS_Datatypes

i1: make hash! 10 ;index subjects

i2: make hash! 10; index predicates

i3: make hash! 10; index objects

http://www.youtube.com/watch?v=xpjVze-YOKI&list=PL-sJ-JyMOF6FcvI-cEK3esrCJaQzmlae0&index=2&feature=plpp_video