World: r3wp

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.

yes.. that's what I mean in my latest posts.

for example:

complete? blk 3

We are taking the SQL attitude towards none, that none and missing 
data are the same thing. This lets us use ANY and ALL to deal with 
missing data no matter where in the series it is missing from.

It's a design choice we made for R3 a couple years ago. Still a good 
choice, IMO.

We are really consistent in treating none that way, which is why 
map! values of none don't display and are skipped.

This makes a clear distinction between none and unset:
- None is missing data where missing data is OK.
- Unset is missing data where missing data is probably an error.

I agree, since its now consistent everywhere, we can expect the reaction 
and know that when its important, we must check instead of relying 
on an attempt or try to catch it.

I didn't yet realize that this decision had been applied so thoroughly 
 :-)  <  that's me with a smile, cause I can use ANY/ALL even more 
 :-D

Yup, instead you can use an ALL to catch it. That is much faster 
than ATTEMPT or TRY, since you don't have exception handling.

I always prefered "NONE" over "NULL"

And ANY instead of COALESCE :)

We have been improving the consistency of REBOL a lot in R3. Alpha 
49 had a lot of consistency improvements, for instance.

its like reading... there is nothing here and here too  hehehe  I 
see none like a portable hole (remember in bugs bunny ;-)

:)

the irony of the portable hole, is that you can actually Take the 
hole... a pretty nice oxymoron  ;-)

(I mean grasp it, move it around)

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

I say it should react the same as skip > length of series.

Nah, Bugs Bunny had just figured out how to manipulate higher dimensions. 
:-) No wonder Elmer Fudd can't beat him.

Not the same thing. If you have skip > length of the series, it will 
only do one iteration and your access to the results off the end 
will usally be none, unless you constrain it yourself. The question 
is whether negative skip should be silently constrained or generate 
an error, as a general rule.

By the way, when you have 1-based indexing, 0 is a negative index 
:)

yep... not the best for the math in index calculations.... hehehe 
but much more human readable for code and human interaction, so I 
still prefer one indexing after 9 years... even if the techy in me 
sometimes lets out a little <sigh>  in trying to get to the proper 
start/end of complex series extractions  hehehe

well, I just realised that it should do the exact same as for the 
end... if you are not currently record  aligned  and are doing reverse 
operations, its possible you'll encounter incomplete records at the 
start.f

having an error in this case would make it toocomplicated to code 
around the error, methinks