World: r3wp

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

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.