World: r3wp

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.

remove accepts none. the others are examples for "give a good value 
for 'if instead of throwing an error".

Well, if you consider index? find to be another way of saying find/index 
(if such a thing existed) then I can see why you would let it accept 
none. If you consider index? to be a seperate function, then accepting 
none would just be propagating an erroneous condition. Remove should 
definitely accept none because it's not much of a stretch to change 
its meaning from "remove here" to "remove here if there is something 
to remove, no-op if inapplicable", the same behavior it has as in 
 remove tail series.

But Remove Tail Series is programatically different than Remove None 
as Tail returns an apparently empty series, not none.

Except in a more abstract sense that  remove tail x  and  remove 
none  both return what they were passed, unmodified :)

is this a bug or am I doing something wrong?

t: func [ip-val [word!]] [
    switch/default ip-val
    [
        'From [print "A"]
        'To [print "B"]
    ]
    [print "C1"]
]

t 'From ; should print "A"

Compared to 

t1: func [ip-val [string!]] [
    switch/default ip-val
    [
        "From" [print "A1"]
        "To" [print "B1"]
    ]
    [print "C1"]
]

t1 "From" ; should print "A1"

which correctly prints "A1"

The first example prints "C1" rather than "A"

t 'From => ?

>> t: func [ip-val [word!]] [
[        switch/default ip-val
[        [
[                'From [print "A"]
[                'To [print "B"]
[            ]
[        [print "C1"]
[    ]
>>
>> t 'From ; should print "A"
C1
>>

shouldnt that have printed A rather than C1

>> t: func [ip-val [word!]] [
[        switch/default ip-val
[        [
[                From [print "A"]
[                To [print "B"]
[            ]
[        [print "C1"]
[    ]
>> t 'from
A

OK ... so I dont need the "'" before the word ..... thanks

I remember being caught on that one once before.

I note that the parts of  dates, times, tuples etc are accessible 
using path notation.
Why not email! as well?

I would suggest that email/1 should be the part before the "@", and 
email/2 the bit after.
Then email/2/1 would access the first bit before the "." etc.

Graham: Are you asking for  email/1 & email/2 to map to the current 
email/user and email/host  refinements ?

oh no!

where was this documented??

under datatypes  http://www.rebol.com/docs/core23/rebolcore-16.html#section-2.3

:)

No doc ? We even don't read the one we have ;-)

Q: is there something to flatten a block of block ?
ie: 
>>> probe a
=== [[1 toto] [2 "this is text" 5.63] [#as12 none]]
>>> magic-code! a
=== [1 toto 2 "this is text" 5.63 #as12 none]

Yes this just came up again recently,

27 april  chat & parse

Thanks, didn't remember that

how is find/match supposed to work on blocks? I thought following 
will work? 

find/match ["Petr Krenzelok"] "Petr"

what I have in mind is very simple kind of select, not needing to 
enter whole search key ...

with blocks, I don't think that'll work with match, because it searches 
for the full element in a series, thus you need to search in two 
levels...

the block level and the string level

a find/deep would be very useful... recursive searching of blocks 
and objects. it could allow you to find a value in large objects 
and blocks quickly

find/deep is long requested feature, but it was said as not being 
as trivial, as blocks can contain self-references etc ...

and what is find/only about?

with find/match you can check for abbreviations

>> find/match "Hello World" "W"    
== none
>> find/match "Hello World" "H"
== "ello World"

>> find/match ["Pekr" "Krenzelok"] "Pekr"
== ["Krenzelok"]
>> find/match ["Pekr" "Krenzelok"] "Krenzelok"
== none

/only is for this:

>> find ["Pekr" "Krenzelok" "asking"] ["Pekr" "Krenzelok"]
== ["Pekr" "Krenzelok" "asking"]
>> find/only ["Pekr" "Krenzelok" "asking"] ["Pekr" "Krenzelok"]