World: r3wp

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

so fill with nones. to prevent the start of the records to shift 
and corrupt the first record.

the algorythm using the /skip is responsible for ensuring that it 
treats the unaligned first value in any case... but the algorythm 
will much simple to write if the offset which is returned by the 
use of /skip doesn't change.

if we align to first item of the block, then what would be the third, 
will become something else, when you hit the head of the series.... 
this adds a lot of complexity to the loop for nothing I think.

Maxim, once you have 1-based indexing (which we are stuck with for 
historical reasons), then having 0 be negative *is* the best for 
math calculations. That way you can count on offset = index - base.

but functions like insert are a bit simpler to use with 0 based, 
since a length is used as the value past an item in a series not 
the last character in it.


they both have advantages.   but trying to explain to someone that 
an index of 0 moves backwards isn't very obvious to promote as a 
feature ;-)


I'd have trouble justifying this to my kid which is learning to do 
math  :-D

brian: any reflections on my post regarding the /skip past start?

/skip is a length, not a index or an offset. I'm not sure what effect 
/skip past start should have.

an example?

gimme me a minute will try to build a little example.

No, I just don't know which post you are talking about so I don't 
get what you are saying.

hum... implementing an example to show, I realise that using skip 
should return an error in the case of series, cause alignment is 
broken, just like sort.

ex:

a: next "1234567890"

probe head move/skip a 4 2

== "1456789023"

in reality there should be something between 0 and 2  if "23" was 
to keep its alignment with its original position within the series.

this sort of stumps me philosophically on how to manage the /skip 
in either direction when you go past bounds.

with blocks we could decide to add nones, but would it be any usefull?

same for going beyond head.

I guess the best action to take is to specify explicitely that /skip 
is meant to handle records when they are aligned. results of un-aligned 
/skip operations are un-defined at best.

(they are aligned === when the series is aligned with the records)