World: r3wp

That is because, c is not a series pointing to another (in this case 
same) series.

Right.

For blocks, inserting doens't change position of other indexes to 
same series. What I expect, is that the insert is from the index 
given, before the insert is carried out. Like:

>> s: [a b c]
>> insert/only s skip s 2
should result in
	[[c] a b c]

, where the first element is a pointer to one before the end of s, 
not two before the end of s as we have today.

In other words, INSERT take two arguments, series and value. The 
value should be picked up before starting the insert, not after starting 
the insert. (If that makes sense.) :)

actually it does as you expect, in first phase.

Here is the trace log (R2)
>> s: [a b c]
== [a b c]
>> trace on
Result: (unset)
>> insert/only s skip s 2
Trace:  insert/only (path)
Trace:  s (word)
Trace:  skip (word)
Trace:  s (word)
Trace:  2 (integer)
Result: [c] (block)

it inserts [c] into s.

The value should be picked up before starting the insert, not after 
starting the insert. (If that makes sense.) :)
 - actually, it does not

But then, the internal pointer changes because of the insert.
>> head s/1
Trace:  head (word)
Trace:  s/1 (path)
Result: [[...] a b c] (block)

>> index? s/1
Trace:  index? (word)
Trace:  s/1 (path)
Result: 3 (integer)

>> s/1
Trace:  s/1 (path)
== [b c]

Now I'm in doubt! Need to think some more. :)

I understand, what happens, that it's a position in a series, I try 
to insert earlier in the same series. I just find it a bit confusing, 
it works as it does. Woldn't it be more logical, if it's the position 
+ 1, that is inserted in such cases? I think, this looks strange:

>> s: [a b c d e f g h]
== [a b c d e f g h]
>> insert/only s find s 'd
== [a b c d e f g h]
>> s/1
== [c d e f g h]

It seems more logical to me, if it does this:

>> s: [a b c d e f g h]
== [a b c d e f g h]
>> insert/only s next find s 'd
== [a b c d e f g h]
>> s/1
== [d e f g h]

So, you prefer lists

You need to realize, that there are implementation differences between 
lists and blocks, and that they are "enforced" by the properties 
of the respective datatypes.

hm, could be. :) Nah, blocks are very cool for many things. I think, 
both blocks and lists are useful though.

It's also interesting, that if /only isn't used, the result is what 
I first would expect:

>> s: [a b c d e f g h]
== [a b c d e f g h]
>> insert s find s 'd
== [a b c d e f g h]
>> s
== [d e f g h a b c d e f g h]

block: [1 2]
index? block ; == 1
insert block 0
index? block ; == 1

list: make list! [1 2]
index? list ; == 1
insert list 0
index? list ; == 2

without /only is more general use of course, but it is completely 
different. In your last example (Geomol) you get the values of a 
series and insert them into another series.

with /only you get a "pointer" to a series and put that "pointer" 
into another series. (I know "pointer" is not a correct word for 
this but you got the idea)

What if I want to insert the tail position of a series earlier in 
the same series?

>> s: [1 2]
== [1 2]
>> insert/only s tail s
== [1 2]
>> s/1
== [2]
>> insert/only s next tail s
== [[...] 1 2]
>> s/1
== [2]

So that can't be done.

So you could have a series which holds "pointers" to other some positions 
in another series, even a position in itself.

s: make list! [1 2]
insert/only s tail s
s/-1 ; []

Yes, works with list as expected.

It is not hard to find out, why it cannot work with blocks the same 
way

It can't? Isn't that just a design desision?

It can't

*decision*

ok, can you explain why or give an example, that clearly show it?

The above list example proves, that lists don't "know" their index, 
and have to calculate it every time, which means, that "index access" 
is slow.

I think, this is only a problem with blocks, if you insert a later 
position earlier in the same block.

As opposed to that, blocks are designed for fast index access, so 
they have to "know" it, which means, that INSERT cannot change it

I don't think, INSERT have to change position of some index, it just 
have to insert the next position than the one given, and only if 
insert is earlier in the same series.

I can't see, it shouldn't work. But we'll see...

I don't think, INSERT have to change position of some index
- that formulation does not make sense to me

index is a number

the one obtained using the INDEX? function

I read you, as INSERT cannot change an index. I say, INSERT should 
just add 1 to the index number, it receives, and only in that special 
case.

INSERT cannot do such a "harakiri"

how could it?

:)

just realize, that index is a number, and every blocks remembers 
it

if it did not, it would have to calculate it every time

and, since the index attribute is immutable, in fact, the INDEX function 
cannot change it

I'm not talking about calculating every time and changing of indexes 
being hold by variables and such. I only suggest, that INSERT does 
this:


If /only and if value being inserted is an index (or position or 
what we should call it) later in the same series, where we are inserting, 
add 1 to the index value and insert that.
In all other cases carrie on as usual.

THat is nonsense, it would be incompatible with the above example 
I wrote

I'm sorry, if it doesn't make sense. I sometimes find it easy to 
figure out such solutions but very difficult to explain it to others. 
:) I'll just go and implement it myself.

You need to realize, that "insert/only a block into a block with 
the same head" has to be compatible with "insert/only a block into 
a block with distinct head"

Otherwise you are asking for any kind of trouble you can invent.

sure, and it's possible to test for that.

Well, the only thing I can suggest you is to try it and see which 
incompatibilities you get.

Geomol, refering to your example above:

>> s: [a b c d e f g h]
== [a b c d e f g h]

>> p: find s 'd
== [d e f g h]

>> insert s 42
== [a b c d e f g h]

>> p
== [c d e f g h]