World: r3wp

CASE/all: could be added to Red/System (would be called case-all), 
but as I'm personally not a great user of CASE/all, I'll wait for 
other users to ask for it. ;-)

Specification: I agree that find the native function is not handy, 
I could remove the "API Reference" level to make it easier to find 
from TOC.

find => finding

BTW, the "manual" is supposed to be a (more or less formal) specification 
of the language, but as I didn't have time to write a separate user 
manual, it now tends to serve for both uses.

New handier (I hope) chapters layout: http://static.red-lang.org/red-system-specs.html

Looks good

What is returned, when no case passes?

I mean, whether that is necessary to have in the specs.

In such case, result is undefined. If you need a return value, it's 
up to you to provide a "catch all" ending rule that never fail.

Out of curiosity, Doc, not criticism, why did you pick the 3-clause 
BSD license instead of the 2-clause BSD?

Just because it looked good to me when I had to pick one. But since 
then, Andreas made me realize that it can be problematic for derivated 
works because of the "prior written permission" part. That is why 
the current Red runtime source code is licensed under the Boost License. 
I think I'll just re-license the whole source base under BSD 2-clause 
when I'll find some time for that.

derivated => derivative (hard remembering this one)

The reason for using the Boost License for the runtime was clause 
two: "Redistributions in binary form must reproduce the above copyright 
notice, ..." .

A Red/System-produced binary linked with the Red/System runtime arguably 
is a redistribution of the Red/System runtime in binary form.

The Boost Software License is even more permissive in this regard, 
and should therefore make sure that Red/System-produced binaries 
can be distributed without any restriction.

Forgot about that, right! So not even the 2-clause BSD is permissive 
enough?

Nope, I'd suggest sticking with the BSL for the runtime.

The heck with it, go with the WTFPL :)

Andreas, you forgot the "in the documentation and/or other materials 
provided with the distribution" - it's iffy as to whether you need 
to provide them in the binary itself. Still, the BSL looks good. 
I should consider it for R2/Forward and my R3 mezzanine work, since 
the MIT license has the same restriction as the second clause of 
BSD-2.

WTFPL looks good. ;-)

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