World: r3wp

the R3 return sort of alleviates the point of the /SKIP refinement 
no?

So am I. I wasn't saying I preferred it, just that I expected it. 
I think this is why I've never used select/skip :(

The R2 method is much more flexible. The R3 method is identical to 
"first select/skip", and I doubt there would be that much gained 
by having a specific alternative function for the R3 method.

I prefer the R2 method
 - I bet noone expected me to ever say that :)

BrianH, not working much with flat blocks, eh?

its like sort/skip there is a simple consistency in the implied records 
which I always like... other languages will have a framework just 
for that...

brian: LOL

I tend to use FIND and SET [w1 w2 ...]

but find will trip if records ands content can have the same datatypes... 
wich is why the /skip refinement makes sense.

(for select)

Sorry, FIND/skip

Maxim, yes. I'd say that if every single REBOL function used /SKIP 
consistently, you could do flat block databases and rely on /SKIP 
without getting your records screwed up.

its almost the case now... sort/skip  find/skip  select/skip

hey, here's a fun one:

a: [1 2 3 4 5 6 7 8]

select/skip a 5 -4

hangs.

which function is fundamentally different in this regards ?.... I 
don't seem to recall one off the top of my head

(in regards to /skip)  post order makes my last post a bit out of 
context

Henrik, is that in R2 or R3?

R3.

I noticed something weird too. If you have multiple R3 windows open 
and switch between them, does the window title change?

select/skip issue submitted to curecode.

The window title thing seems to be related to marking up text in 
the console and is not caused by R3. Never noticed that before.

it seems FIND/SKIP does the same thing. :-)

Alpha 50 released.

7 reports with /SKIP issues.

Clearly we are going to need a /SKIP doc in R3/Language/Options.

Agreed.

I wrote MOVE, so talk to me. How should MOVE with negative skip work? 
Allowed or denied?

I don't really know. I guess we want consistency?

From what I can see the correct way is to provide an out of range 
error on less than zero.

move is like next but modifies the series itself?

We don't have consistency, so I figured I'd start with a fuunction 
I understand.

should say move is like skip

No, move actually moves stuff.

move: make function! [[
    "Move a value or span of values in a series."
    source [series!] "Source series"
    offset [integer!] "Offset to move by, or index to move to"
    /part "Move part of a series"
    length [integer!] "The length of the part to move"
    /skip "Treat the series as records of fixed size"
    size [integer!] "Size of each record"
    /to {Move to an index relative to the head of the series}
][
    unless length [length: 1]
    if skip [
        offset: offset * size: max 1 size
        length: length * size
    ]
    part: take/part source length
    insert either to [at head source offset] [
        system/words/skip source offset
    ] part
]]

ok, like a change remove combo

Right, but safer.

BrianH, do we want consistency across all /SKIP or not? That is a 
big issue. Personally I would like it.

We want consistency. We don't have it yet. So this is a start.

OK. The solution would be to generate an out of range error for skip 
<= 0. DIFFERENCE does that correctly.

I wrote the other standard option specs after much discussion. We 
need that discussion before I can write the /SKIP spec.

I would really like the /skip to be consistent as "implied fixed 
record" it would make flat record management and "explicit" feature 
of REBOL.

Right.

I second out of range error ... including for partial records if 
 it goes beyond the last complete record

the partial (last) record consistency is part of the /SKIP feature 
set wich must not be forgotten.

So the question is whether we want an out of range error, like DIFFERENCE, 
or to constrain to 1 silently, like MOVE.

IMO a partial record is valid, until you try an option which would 
break the /skip alignment... so sort/skip with inclomplete records 
would always be invalid.

Maxim, in R3 bounds checking like that is mostly obsolete for blocks. 
Values off the end of the block are treated like none in the block.

so sorting an incomplete /skip would add nones into the block?

I'd rather have an error, than a corrupted data set.

So FIRST [] returns none. I don't know about SORT though - you make 
an excellent point. EXTRACT adds nones, but doesn't change the original 
block.