World: r3wp

So how is it not a bug if you tell it to start at index 22 and there 
is no index 22 and it  is returning none?

>> a/22

sorry

>> a/22
== none

in 2.7.6:

>> b: extract a 2
== [1 3 5 7 9]
>> b: extract/index a 2 22
== [none none none none none]
>> b: extract/index/default a 2 22 'potato
== [potato potato potato potato potato]

I know that a/22 is none but shouldn' t it instead react like other 
REBOL entries in this regard and say "out of range"?

if it did that, we'd have hundreds of cases where we'd need extra 
error handling. in fact, R3 produces more cases where it returns 
none, than R2 does. it's just simpler.

Not a fan of how it returns values.

the error checking you could do, would be to check for the range 
first and then pick your value, if the index is in range.

well, you'd have to write a lot more code, if it returned an error.

I don't have to do none of that with skip+

>> a
== [1 2 3 4 5 6 7 8 9 10]
>> skip+ a 2 22
== none

I can see you are worried about whether the returned none! is a value 
in your block or if it's out of range.

exactly

another reason extract does this, is to keep the block datatype for 
output. again you need to produce much more code, if the datatype 
is changed in the output.

you don't have to worry if you just check if the index is in range 
first.

skip+ keeps the output in a block as well:

>> skip+ a 2 3
== [3 5 7 9]

not when it's out of range :-)

exactly.  I wouldn't want it to more often then I would

much easier to do:

to-block skip+ a 2 3 


then to determine if a none is an actual value being returned of 
my series.

but... anyway, it's just two different principles. I prefer to do 
the error checking before doing operations in the series:

a: [1 2 3 4]
b: 7
either tail? at a b [print "whoa!"][extract a b]

That is defeating the purpose of a mezz.   The mezzanines are so 
we don't need to use more code.

Makes me think we should have a poll for mezzanine changes.  Let 
the community decide.  Could be very beneficial to REBOL.

how will you do error checking with less code in the example above?

I'm saying with skip+ it is already done for me.  I can tell if something 
is out of range if it returns none.

sure. that's why I think is impractical for cases like:

foreach val skip+ a 2 3 [do-something]


you will get a crash, when it returns none, and you will still need 
to do some type of range check to avoid the crash.

i'm going to use extract for what I'm doing since I already am doing 
error checking on the front side in my scripts where I'm going to 
use extract but I'm only going to use it since it is built in.  But 
I'd rather see something similiar to the returns that skip+ provides 
instead.

Lastest Makedoc draft of TRETBASE for public download:

http://www.mediafire.com/?x8yu1mrl724

sorry wrong group

; I liked this feature of ICON/UNICON where a func can have an initially 
block so I have this in REBOL
initial: func [wd [word!] /list /local functions]
  [
    functions: []
    if list [return functions]
    f: find functions wd
    either (found? f) 
      [return false] 
      [append functions wd return true]
  ]    


initially: func ['wd [lit-word!] blk [block!]][
    if (initial wd) [do blk]
]
; and to test initially
test: func [str [string!] /local prefix [string!]][
    prefix: ""
    initially 'test [prefix: "tested "]
    print [prefix str]
]
; which runs as, say
test "this"
; first time giving "tested this" and thereafter "this"
; thoughts on whether useful enough to go into the org library ?

; of course initial itself test more simply
>> initial 'append
== true
>> initial 'append
== false

Paul, the changes to EXTRACT are part of a whole series of subtle 
changes to REBOL that are based on 3 ideas:

- NONE is a value that denotes no value, like UNSET but not an error 
- sort of like SQL NULL.

- Out of range isn't necessarily an error - you can choose to treat 
it as such as you like, or not. Boundaries are really an implementation 
detail in a language with autoexpanding series. The choice to have 
fixed boundaries is left to the developer.

- There is no difference between a NONE in the middle of a series 
and a NONE off the end. It's a missing value either way.


REBOL worked this way already in many cases, so we're making it more 
consistent.

Creating, evaluating, throwing and catching those error! values is 
really expensive - nones are much faster. Also, these error! values 
are generated in many cases now where the situation isn't really 
erroneous, which is a little presumptuous.

I just don't like it Brian.  Like Henrik noticed I have a problem 
with it because it returns none as a value inside of the series. 
 I rather have it report none as a none! When it is reported as it 
is currently in extract it isn't a none! datatype it is a 'none word 
value.

Skip+ does it find BrianH and I don't have to catch any errors.

And it returns a none datatype if out of range.  I don't have to 
check for "out of range" as the none being returned tells me that.

Sorry, I don't get something. Are you saying that EXTRACT is returning 
the word 'none rather than the value #[none], or that you are using 
the word 'none in your series for something else?

It is returning the none in the block when I could actually already 
be using the word none in the block

So if I'm using 'none in the block and it is returning #[none] then 
I have to check to determine if the value returned is a none! or 
a 'none.

Let's make a distinction here: The word 'none, the value #[none]. 
EXTRACT returns the value #[none]. What are you using 'none for?

Sorry, AltMe is locking up on me again. I wrote that message 2 minutes 
ago.

Sometime I use the value none to specify that position in the series 
doesn't currently have a value.   I'm sure many have done this.

That is how EXTRACT treats #[none], every time.

Brian did you create the EXTRACT function or something as I can't 
see how anyone would prefer its return value over a simple return 
for general use.

So your problem isn't with EXTRACT treating #[none] as no value, 
it's with it treating out-of-bounds as a non-error.

Both

Did you try the skip+ function from above?

I looked at skip+ above and could see from the code what it does.

Notice here:

>> a
== [1 2 3 4 5 6 7 8 9 10]
>> skip+ a 2 1
== [1 3 5 7 9]
>> skip+ a 2 11
== none

Simple from its output I can tell that the index was out of range 
by the none that was returned.  Can't tell that from extract.