World: r3wp

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.

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 ;-)

:)