World: r3wp

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)

with this detail in place, and with blocks, I'd say it would be usefull 
to pad with nones.

Give me a moment and I can answer your concerns.

with strings... I guess you stick to head.

to create an empty record set of 30 records would be as easy as:

rs: move/skip [] 30 3

I have difficulcy to get Chat files. I do nf, to list new files, 
then I submit get * but nothing is synced. I try other aproach, going 
to e.g. R3 mezzanines section, and doing get * does either report, 
that there was no change to files, or that my local copy is changed, 
and hence it can't be synced. I am sure I did not do any local changes 
here ... So - how do you usually work with Chat file facility?

I usually purge the directory when I'm not working on the files. 
Then when I want to work with them I get the specific files I want 
to edit, edit them, test them locally, submit the changes, then empty 
my work directory. If my submission sucks I deny it, if it is good 
I accept it.

If I want to keep local versions to compare to I keep them in another 
directory, then compare to the changes made by others. I only need 
to do this when I am working on the same file that others are working 
on, usually a sign that there is too much in the file (it needs to 
be broken up), or that I need to do a better job of talking to the 
other person.

Situations like that are why DevBase and chat are integrated now.

OK, Maxim, the MOVE/skip example you specify is not an error in MOVE, 
it is an error in the code calling MOVE in that example. MOVE was 
specifically designed to do something useful in that case, rather 
than generate an error.


The whole reason that MOVE takes one position and one offset is because 
that limit gets rid of a host of potential aliasing errors. MOVE 
is designed to be the most efficient and safe solution to the problem 
of moving stuff, and it should *never fail* unless the series is 
protected from changes. MOVE is a DWIM function: Do What I Mean. 
This goes for treating negative /skip lengths as an error too - having 
it magically constrain the /skip length to 1 or greater was a deliberate 
design choice, the result of a lot of discussion.


So the question is whether the error of having /skip lengths being 
less than 1 is worth worrying about, worth the overhead of generating 
an error and checking for that error every time you use the function. 
Don't be fooled, that overhead is really significant.


We've already changed other functions so they don't generate errors 
anymore, and just DWIM, like FIRST not complaining about bounds and 
acting like PICK 1 now. These changes have made these functions faster, 
and better to use. Generating an error is considered something to 
do when it is really important, as it sometimes is. How important 
is the /skip < 1 error?