World: r3wp

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]

Extending this to your insert/only observation, the behaviour is 
perfectly consistent.

Whereas with your awful proposed insert/only-hack, it would not.

I see no problem with your example. I'm surprised, you find my suggestion 
"awful". What's awful about this:

>> 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/only s p
== ....
>> s/1
== [d e f g h]
>> p
== [c d e f g h]

John, remember our previous discussion, that indexes are not properties 
of series, but properties of series references. Therefore, it makes 
no sense to try to make a vector behave like a list, because any 
other references to the vector are unknown and thus it's impossible 
to make the behaviour for those references consistent

The awful property is as follows:

s: [a b c d e f g h]
t: [a b c d e f g h]
p: find s 'd
insert/only s p
insert/only t p
same? first s p ; == false !
same? first t p ; == true

That's a strong point!

I'm really wondering what's up with Carl.

If he shows up (maybe once every 6-8 weeks) only for 1-2 minutes...

If he lost faith in Rebol-3?

And, I don't understand why he can't be reached. All available channels 
are dead...

Probably trying to build a big antenna to phone home

Doesn't he have a phone?  Or did he give away his iphone?

So Robert, you also haven't been in contact with him? I thought he 
was working with you all this time. Hmmm.

Last spotted this tuesday in the RM Asset world, but no feedback 
so far.

Robert I have the same questions you have. Carl must acknoledge that 
our life and companies are waiting for him.

This is by far the longest period of Carl's disappearance, IIRC. 
The reasons we can only speculate about - some personal/family difficulcies, 
burn-out to the REBOL topic, new daily job, which does not   left 
you with much energy and free time to do some other stuff, REBOL 
related.


We tried to get Carl's answer on R3 Chat, only with sporadic answer 
of recent Carl's job. But no answers to "what's next" for the REBOL. 
The reasons might be various again - Carl is willing to proceed, 
he just dosn't have time/energy. He is most probably not willing 
to open-source the project either, which gets us into kind of schizophrenic 
situation - no open-source, no progress either. If Carl would know 
the answer to what's next for REBOL question, he would already share 
it with us. But he did not do so, yet, which is a bit disappointing 
of course.


As for a phone call - I don't know - I would not call him, as it 
could get him into feeling, that we push him to give us an answer, 
which he might not have right now. But - I think that call from some 
friend, e.g. Reichart, would be accepted differently. But then - 
we can't push anyone to do anything, and from few weeks old discussion 
I think that Reichart does not necessarily feel urge to do such a 
thing, which is OK too.


So ... we wait ... and RED progresses at least, so hopefully in the 
end, there is still the chance that we will see the light in the 
end of the tunnel :-)

Let's focus on Red and Cheyenne now.

And let's hope Carl and his family are alright. No illness no accident.