World: r3wp

compare:

1 + index? any [find "abc" "e" #]

to:

1 + any [index? find "abc" "e" 0]

maybe index? should directly return zero.

But then you need to have a test against zero in order to catch a 
not found result.

but when you found nothing, there is no index. 0 would give syntactically 
valid results, letting the rest of the program run. just doing wrong 
things. none will at least led to trapping it.

thinking about it, when using series instead of indices, it bails 
out on using, not immediate too. maybe index? pasing none is k.

The problem with returning zero is that is an attempt to handle implcitely 
something that should be explicit, that is error catching.

I vote to leave it like it is.  It makes the most sense to have Index? 
fail on a non-series value.  I've found ANY to be a very handy function 
for handling things like that.  I initially just used it with EITHER 
and IF but its starting to show up in a lot of places in my code 
because it is just nice and concise. ;-)

is not finding a value an error? i think it isn't.

ammon: see above, if you use ANY you get 1 which is hardly what you 
want.

Not finding a value is not necesarily and error, that the reason 
find returns NONE. But it is an error to request the index of none.

Changing the semantics of INDEX? NONE is what is at stake.

That is true but that just means that it may not be the way you want 
to handle it.  I think Ladislav is correct here.  In some situations 
it may not be bad to continue with a bad index value but I think 
the majority of the time then you need to cancel what you are doing 
if the index is not available, hence an error.

Jaime, Agreed!

Jaime: for INDEX? used alone, that may be true. But asking the position 
of a value in a series and asking the index of a value in a series 
are, IMHO, the same question.

pos: find series value

idx: index? find series value

so if the former should not cause an error, neither should the latter.

but then give 'none, not 0.

That sounds better. NONE = INDEX? NONE

But then you run right back into the problem of having to check for 
a NONE value on the index variable because the code using it is undoubtedly 
going to fail on NONE because it is expecting a Number.  Any way 
you look at it you are going to end up needing to check for that 
NONE value.

Checking for a none value is easy with the ANY native. It's just 
like using COALESCE in SQL.

Yes, there are many ways to check for NONE and most of them are easy 
I'm just not sure how much value it would actually add to have Index? 
return NONE when passed a NONE value.

as gabriele says, we have the same problem with series. can be none 
too and fail then.

and Henrik likes better flow. i guess something like
 if index? find data value [ .. ]
or 
 any[ index? find data value  default ]

since i rarely use index when i can use series, i don't know how 
important thatis.

The only time I've found it useful to use index is when using values 
in one series as a key to values in another series. Kind of rare 
when you have select/skip, but sometimes you don't want to modify 
the data series. All right, since RAMBO says that there are problems 
with select/skip right now, maybe not so rare.

IIRC that problems relate to select/skip on strings, which is not 
very common anyway.

The reply said the bug applies to blocks too.

Using Select/Skip on a String! doesn't behave in a manner consistant 
with the way that it acts on a Block! which leads to a state where 
it freezes the REBOL Interpreter.

iOops, ok, i cant read.. yes, you are right.

(no freeze, but wrong result with blocks, ok, ok.. )

For 8bit character strings I often prefer using a 256 byte binary 
lookup string indexed by the integer equivalent of the relevant character.

That doesn't work too well with Unicode though, unless you implement 
sparse lookup tables.

Still, what is the difference really between any [index? find data 
value 1 + length? data]  and  index? any [find data value tail data] 
 ?

The former being the version you could do if null handling were added 
to index?, the latter being the way you can do the same thing now.

that an error is not flagged in the second way.

the result is more or less valid. think you insert something in the 
block, then rebol will hapilly fetch at that index.

with none that does not happen. you can either keep is as none, or 
give it some value you really want. or you can use 'if and only act 
if found.

if ix: index? find data value [ print ix ]
instead of
   if pos: find data value[  ix: index? pos  print ix  ]
the first "flows" better.

You misunderstand my point. Since Henrik was suggesting that  index? 
none  be changed to a non-erroneous condition to handle certain coding 
patterns, I was showing an example of such a pattern that can be 
accomplished with the existing index? behavior. The advantage to 
the existing index? behavior is that it forces you to deal with exceptional 
(but not erroneous) conditions closer to where they occur, and thus 
make your code easier to debug. I would write the second version 
of your example as  if pos: find data value [print index? pos]  which 
flows just as well as the first.

REBOL doesn't have lightweight exception handling like Icon - it's 
a lot easier track propagation of exceptional conditions by setting 
up the flow on purpose.

thats one way to see it, which i partly share.

but with series its the same kind of exception, and Gabriele argues 
we could deal with it like we do with series: give none and trap 
on access.

and the "flow" in such cases is to use the patterns i showed, with 
'if or 'any. and not forcing an extra assignment.

(or putting the "index? pos" somewhere in an expresion where it bloats 
and confuses a bit)

Which of the other series functions also work on none, instead of 
just returning it?

I like the current behavior, because in my experience with null and 
unknown in SQL, tracking the cause of the unknown to its source can 
be tricky. It is easier to find out where that none came from if 
it doesn't propagate very far unintentionally. A meaningless none 
should be converted to a meaningful default while you can still tell 
where it came from.

remove was changed to work with none. about propagation versus comfort, 
i am undecided in case of 'index? . good flow makes programs easier 
to understand. OTOH you are right about eraly error-trapping.

also working with none: 'select (retuns none instead if throwing). 
pick returns it when out of range.

I meant accepting none, not returning it.