World: r3wp

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.

Let's say that modifying functions should error out if the block 
is there would be data corruption (just SORT, I think), but retrieval 
and builder functions should act like the series is none-padded.

in a sense, EXTRACT, being a column selection for a flat record system, 
would mislead the dataset analysis.

I'd really prefer having an error, cause I can't know if there really 
is a none there of if its missing.


these decisions are always tuff... integrity or productivity.  large 
apps require the former, throw away code ususally prefer the later.

if the block is there would be data corruption
 -> "if there would be data corruption"

maybe, as a helper for explicit flat record handling we could add 
a really simple func which returns true/false for complete records. 
 its not that its hard to write, just that its cleaner if we all 
use the same func for it.  what do you think?

Maxim, it was decided that for R3 the bounds of a series were more 
of an implementation detail, not an error. A none in the middle of 
a block is considered the same as a none off the end of a block. 
That is why the ordinals (first and such) act like PICK now.

then, if someone really needs partial record detection he can know 
before knocking code on it.

I  usally use none as a no-value/don't care/error especially since 
I use ANY/ALL a lot, but for records, none and missing data are completely 
different.

If someone needs partial record detection, they can do it ahead of 
time. We're trying to make REBOL only generate errors when it's useful 
to do so. It was not deemed useful in this case.