World: r3wp

SWITCH native implemented in Red/System, here is an example of supported 
features:

a: 5
ret: switch a [
	0 	[print "0" 0]
	1 #"^E" [print "1" 1]
	2 6 	[print "2" 2]
	3 	[print "3" 3]
	default [print "no match" -1]
]

print [lf ret lf]

* Mutiple values allowed (even mixing integer! and byte!)
* Returns last value
* Optional default clause

Also the SWITCH argument can be any valid Red/System expression.

Are the clauses you are matching (minimally) evaluated, or unevaluated 
like in REBOL? Would the default clause conflict with a: 'default 
?

Gabriele used this model instead for Topaz:
ret: switch a [
	0 	[print "0" 0]
	1 #"^E" [print "1" 1]
	2 6 	[print "2" 2]
	3 	[print "3" 3]
] [
	print "no match" -1
]

That's a mandatory default clause, which can be empty.

Up to you of course :)

Unevaluated, but only integer! and byte! literals are allowed.


[ a: 'default ] No word!, this is Red/System, not Red. :) Anywhere 
adding words as symbols only in Red/System might not be a bad idea 
in future.

Characters are bytes in Red/System, right, I forgot.

What does SWITCH return when you don't have a default clause and 
none of the choices match? None? Some undefined value? Trigger an 
error?

Topaz's SWITCH: that's an alternative syntax that is closer to the 
REBOL's one. I think that most users will hit the "I forgot to put 
the empty [ ]" issue at least once, so I'm rather for the "optional 
part should be optional" approach.

Same as for CASE: undefined value.

Suggestions for improving that are welcome (both for CASE and SWITCH), 
as long as they don't require a lot of additional coding.

Do you have something like unset!, or is it really undefined? (I 
hate undefined behavior in a programming language, pet peeve)

For that matter, do you have something like the none! type? Nullable 
types are the subject of a big debate in PL design right now.

It's just undefined (probably returning the SWITCH/CASE argument 
value, but that would be implementation-dependent, and could be changed 
in the future).

Yuck (no offence). Triggering an error or returning none would be 
better. There are even some languages that trigger an error on compilation 
in that case, but that requires either an interesting type system 
or some dataflow analysis, so that is not likely a good idea to put 
in Red/System.

None! type: no, Red/System has null and 0, but no first class datetype 
for that.

datatype

Any runtime error triggering in Red/System? Not that I suggest it 
(I prefer the Go approach), but I'm curious.

None! type might not be a so big burden to implement and support, 
but it is just not required for implementing Red, which is the main 
purpose of Red/System currently. If current Red/System users can 
come up with good semantics for such type, I could examine the case 
for implementing it, though.

No runtime error triggering yet. But the runtime error sub-system 
is implemented and used internally.

I mean no way for user to trigger specific errors yet.

Variables are statically typed in Red/System? That would make the 
none debate more interesting.

Also, TRY could be implemented too, but as Red/System will be used 
from Red, I am not sure, this is necessary to support.

Variables are statically typed, yes.

I know it's a bit frustrating currently, as we could add a lot of 
sophisticated features to Red/System, but that's not the plan. :-) 
Most users will never touch Red/System once Red gets available.

That brings up the nullable types debate then.

Is the compiler capable of showing warnings? CASE and SWITCH without 
default cases might merit one. A caveat emptor approach might be 
bese for a C-like intermediate language, I guess :-/

bese -> best

Warning: yes, currently only one is active for signaling useless 
type castings.

I am not a big fan of warnings "à la C", I debated myself several 
times to decide on keeping it or not (converting it to a compilation 
error).

It's not possible to statically analyse for default rule in CASE 
(no keywords, could be any expressions returning always TRUE).

Emptor: I'm not familiar with this concept, googling about it....

Oh, old Latin, shame on me! :)

Can you analyze EITHER, CASE and SWITCH to determine whether the 
results the clauses return are the same type? I guess the same would 
go for ANY and ALL, if you have those.

Yes, that is already done in the current implementation to allow 
the use in expressions.

ANY/ALL: yes, see http://static.red-lang.org/red-system-specs.html#section-9

Do you have a value you can return when the value would be undefined, 
which would cause an error to be triggered if you try to use it in 
an expression? If so, CASE and SWITCH could have an implicit default 
case that returned such a value, and the compiler could optimize 
that out if the CASE or SWITCH return value is not used in an expression. 
That would solve the problem without resorting to nullable types.

Do you have a value you can return when the value would be undefined

 Yes, zero. It could work for all current datatypes: 0 for numbers, 
 NULL for pointers and FALSE for logic! (all are implemented using 
 0 as value internally).


...which would cause an error to be triggered if you try to use it 
in an expression?
 No.

The first option could be easily implemented, probably just a line 
of code or two to add in the compiler.

Well, since triggering the error was the point of all that, I guess 
not. We're back to caveat emptor.

It would need to be something distinct from 0, since that could be 
legitimate.

Thinking about it, I believe that I could hardwire a runtime error 
in CASE/SWITCH in case of unmatched value and no default.

I will test that later tonight.

It would probably be the best option currently.

There are languages that don't allow CASE or SWITCH to have an unhandled 
expression, to cut down on errors. Your suggestion would have that 
effect. It would improve the developer's code discipline, leading 
to fewer errors in the code.

With current CASE in Red/System, it might be required to force the 
use of a 'default keyword, as in SWITCH, for the compiler to know 
if a default clause is used or not in a deterministic way.

Done a quick implementation test on SWITCH, it seems to be working 
fine.

(will be back in an hour)