World: r3wp

Specifically for dynamically allocated series.

you can always use skip -n if you want to jump relatively in a series.

to me it just seemed more REBOLish to use AT in the manner that I 
posted.

Follows the KISS principle to me.

I can update the ticket if you like. What would you like it to say?

INDEX? can return the result of your calculated position. Your example 
would be:
AT series1 INDEX? BACK TAIL series2

Wait a minute - Carl's method is simple things should be simple to 
do (STSBSTD).  A longer acronym.

You can write what you want.  It is just a placeholder for me to 
not suggest it again.

I'm not downplaying it, I'm just trying to clarify. At this point 
I don't understand what you want well enough to answer the question.

I don't understand it either... what should be result of your example 
code?

i think he wants AT working like COPY/PART (the index could be an 
integer or a serie aswell)

Well, if the index is a series offset, even a calculated one, then 
you can already have a reference to that offset without the AT.

It makes sense if the 2 series are differents.

but i agree, i don't see so much use cases for that.

>> series
== [1 2 3 4 5 6 7 8 9 10]
>> series: at series back tail series
>> series: [10]

>> series
== [1 2 3 4 5 6 7 8 9 10]
>> series: back tail series
== [10]
The AT is implied by TAIL, and then again by BACK.

yeah only example I can think of.

I had it written down from something I had been working on.  Go ahead 
and resolve the ticket if you like - if I come across the problem 
that resulted in my notes then we can revisit it.

An example where you are trying to go to the same position of another 
series would be more useful, since that would mean removing an INDEX? 
function instead of adding an AT function.

Yeah in my notes I have "no copy'" so something I was involved with 
wanted the fucntionality without copy.

Interesting. No copying is going on here, just references passed 
around.

Ahhh, just AT series back tail series.

so in other words the following:

at series back tail series

The assingment is implied.

no need to set series: at series back tail series.  But instead the 
at command is manipulating the series directly for the navigation 
arguments.

Wait... Are you Paul ? really ?

Yes Steeve.

No, the at series is implied. The assignment is also implied for 
ports in R3 though.

Never left.

Do you get what I'm saying Brian?

not explaining it well I don't think.

I got two conversations going on - one here and another with Graham 
on his server.

I get what you're saying, but AT is still not modifying for series.

Yeah I know but in this case if it has a navigational argument I 
was thinking it should.

Naw, the navigational functions are just functions for series - except 
++, -- and FIRST+. They are only modifying for ports. By design :)

Can I modify my ticket to better reflect what I was trying to communicate?

Sure. I haven't reviewed it yet in case you wanted to.

I will in a few minutes.

Wonderful bugreporting by Ladislav. Thanks.

http://www.rebol.net/r3blogs/0207.html- Should UNSET act as a value?

(continued from !CureCode) When the time comes, the Parse Proposals 
will need to be reorganized so that there are separate sections for 
general operatioons, and for the operations that are specific to 
blocks, strings, binaries, ports. At the very least, there needs 
to be good binary pattern recogntion operations.

Having the copy operation when applied to a binary! return a binary! 
is an improvement of R3 over R2 already though :)

Steeve, it's not working..
>> str: to-string #{C49BC5A1C48DC599C5BEC3BDC3A1C3ADC3A9313278}
== "ešcržýáíé12x"

>> parse str [some [copy tmp 1 skip (probe tmp)]]
c
ž
á
é
2
x
== true

(you will not see correct chars here probably)

but you can see, that the skip is not working as expected.

parse/all

That's an error - using /all shouldn't fix it because there are no 
spaces there.

Write it up in CureCode.

hm.. than it's ok... BUT there are no spaces inside the string, so 
why /all ?

Because it's a bug.

yes... I was slower than you:)

A bug in PARSE.