World: r3wp

What's the advantage of using words in blocks? 
ie: [a "one b "two] vs ie2: ["a" "one" "b" "two"]

seeing you run out global word space very quickly?

dialects and selection

ie2/("a")
>> "one"

so dialects then?

yes, and the code readability maybe - ie2/("a") vs ie2/a

using words as table keys is probably not a good idea.

why? because of word limit? or any other consequences?

limit, forbidden chars, etc.

word comparison is faster than string comparison

(word comparison is O(1), while string comparison is O(n))

moreover, words have context, strings don't

Is it a benefit, that SWITCH is case insensitive?

>> s: "aA"
== "aA"
>> switch s/1 [#"A" [print "A"] #"a" [print "a"]]
A

use strings not chars

On words in blocks, if you use strings they may be duplicated as 
you copy blocks, which words aren't.

On SWITCH, I think it's consistent with REBOL in general.

Steeve, no, doesn't work with strings:

>> switch s/1 ["A" [print "A"] "a" [print "a"]]
== none

s/1 is a char! And SWITCH won't find it with a string.

Gregg, "consistent"? Ahh... ;)


I was thinking about changing the string into a binary. What would 
you think FIRST used on a binary returns? I would expect a binary, 
but it's actually an integer. I sometimes have a hard time seeing 
the consistency in REBOL. But I know, it's hard to find the logic 
way in all this. So many datatypes. :)

Also changing s/1 to a string gives unwanted result:

>> s
== "aA"
>> switch to string! s/1 ["A" [print "A"] "a" [print "a"]]
A


So I end up with getting the integer value of a char to make this 
work:

>> switch to integer! s/1 [65 [print "A"] 97 [print "a"]]
a

Not so good, as I see it.

Ah! it's probably impossible to convert a char! into a string!, so 
forget it...

hmmm. I just realized that you asked for insensitive case

Yes, I need to test on chars in a string, and #"a" should be different 
from #"A".

The only way using SWITCH, I see, is to operate with ascii values, 
and that isn't good.

well, just use parse instead, its mostly the same structure than 
a switch.

parse/case s [
	#"A" (do something)
           | #"a" (...)
           | ...
]

Yes, parse can be used. My motivation was thoughts about switch. 
It seems, it could be improved.

REBOL3 is pretty consistently case-ignorant in this regard:

>> #"a" = #"A"
== true

And the SWITCH behaviour is just consistent with that.

(R2 is more inconsistent in this regard, as #"a" = #"A" is false, 
but SWITCH behaves case-insensitively, as you described.)

>> #"a" == #"A" 
 
== false

Perhaps SWITCH needs a /Strictly refinement?

SWITCH used to be a mezzanine, so you could easily patch it if you 
want. This is the old mezz source.

switch: func [
    [throw]
    value
    cases [block!]
    /default case
][
    either value: select cases value [do value] [
        either default [do case] [none]]
]

I use SWITCH very rarely, but I don't know about others.

/case would be more consistent with 'find, 'parse, and 'select than 
/strictly would

The char! datatype has many similarities to numbers. The following 
is from R3 and looks strange to me:

>> var - 32 = var
== true


What variable is equal to it's original value, even if you subtract 
32 from it?

>> var: #"a"
== #"a"
>> var - 32 = var
== true


A bit strange. I would prefer SWITCH to distinguish between #"a" 
and #"A".

>> (var - 32) = var
== false

This can be even more complicated when talking UTF encoding. Hm, 
who knows how R3 do this...

Rebolek, do it in R3.

I'm not sure what exactly [var - 32 = var

Ah, ok, this was R2.

Yes, in R3, it's true.

I agree with you, this is strange.

>> #"a" - 32
== #"A"

>> #"a" - 32 == #"a"
== false

>> #"a" - 32 = #"a"
== true

it's ok to my mind

Izkata: /strict could also striclty equal to numbers to give an alternative 
to :

>> number: 1

== 1
>> switch number [1 [print 1] 1.0 [print 1.0]]

1

>> number: 1.0

== 1.0

>> switch number [1 [print 1] 1.0 [print 1.0]]

1

I think the var - 32 scenario is fine as well. It's all about context, 
and by making it work the other way, you're just shifting the problem, 
not really solving it. That is, something becomes easier, but something 
else becomes harder.

Gregg, are you really sure, you mean this? As I see it, the life 
would be much easier, if "a" equals "A", but #"a" didn't equal #"A". 
As it is now, it's really problematic testing for different characters 
in a string using SWITCH. Cases where "a" and "A" should be handled 
as the same is ok, but cases where they should be different is the 
problem. If #"a" was made to not be the same as #"A", then both situations 
could be coped with easily.

At the moment Switch is consistent with Equal?. Surely, it would 
be better to retain that consistency and have a /strict refinement 
for switch which perfomed consistently with strict-equal? ?

Peter, the equal thing is correct for R3, not R2, which we still 
get updates for now and then.

In other words, SWITCH is not consistent with EQUAL in R2, when talking 
the char! datatype.

You are correct, I was mistaken about the R2 behaviour.

First, it should be consistent between R2 and R3 if at all possible. 
For SWITCH, I think the solution is to add a refinement if people 
think it's needed. If the new native SWITCH is still based on SELECT, 
adding a /CASE refinement shouldn't be hard.


For the more general case of char case-sensitivity, we have ==/strict-equal?