World: r3wp

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.

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