World: r3wp

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)

I think that the addition of a default keyword in CASE would be an 
improvement.

Ok, runtime errors added to both SWITCH and CASE, raised when no 
clause matches. No change were necessary for CASE.

Peter: I followed the same syntax as REBOL for CASE, but I am unsure 
that adding 'default keyword would be better. On one side, you have 
a better compatibility with REBOL, so easier for all REBOL old timers, 
on the other hand, we break compatibility (on syntax level only), 
but have a more consistent syntax inside Red/System.


Also the CASE semantics do not require a special keyword for making 
a default clause.

Need some time to think about it.

Silly question: Does C-string mean that it's a C-compatible string 
type and whether there will be other string types in the future?

In short "yes". C-String in Red/System is simply a null terminated 
list of bytes. As I understand, strings in Red will support unicode 
but Nenad hasn't decided what form they will take yet.

If the compiler is only looking for 'default inside a switch statement, 
a good solution may be to #define defaiult as true in common.reds 
and then I can write

case [ a  = 1 [b: 1] default [b: 0]]

and old REBOLers can write 

case [ a  = 1 [b: 1] truet [b: 0]]

truet -> true

On the other hand, even if the syntax changed and default was a keyword, 
the old REBOLers could still write

case [ a  = 1 [b: 1] true [b: 0]]

and belt-and-braces types could write

case [ a  = 1 [b: 1] true [b: 0] default [b: 0]]  ;-)

Topaz SWITCH changed since then.

You have SWITCH and SWITCH-DEFAULT now.

Other strings in the future: for Red/System, possible but very low 
priority for now. Red will have a R3-like string! datatype with Unicode 
support.

Red/Systerm ARM port on OSNews: http://www.osnews.com/story/25468/Red_System_Language_Gets_OS_X_ARM_Android_Backends

Kaj did it again. :-) Thanks a lot! I hope that the article comments 
won't be too harsh. :-)

It has little to do with Syllable this time, but I'm sure our Syllable 
house troll will still manage to make an appearance. Sorry for that

No comments until now, only one 'like' ...

That's typical when people don't know what to think about it - which 
is typically the case with REBOL and Syllable topics :-)

There are seven retweets, though, and the page view counter on the 
Red site has suddenly broken down, but last night shortly after publication 
it had already gone up by two thousand

The "Like" was me.

Cool, thanks :-)

The counter works again, and there are about 4000 extra views so 
far

Note that there are many links in the article, so not even all readers 
will click to the Red site

Oh, there are eight retweets, some by people with many followers

So far 2500 page views today, 1300 yesterday.

When Red 1.0 is out, I promise 10k page-views from China. :-)

Why not now? :-)

Basics of sales: you have to present three times before you make 
a sale

Current counter: 3500 page views today.

Around 450 are coming from my last news on freecode (ex-freshmeat): 
http://freecode.com/projects/red-language.

Forgot that my news was from 26 december, so all current traffic 
is from OSNews.

Mac isn't tagged as an OS on Freecode

Thanks for noticing, I've added it (should be online by tomorrow).

I did research on the atexit() issue. The situation is horribly convoluted

I made an implementation for Syllable Desktop based on __cxa_atexit. 
You could try that on ARM Debian

However, x86 GNU/Linux does have atexit. Also, the cURL binding imports 
atexit through the C library binding, so if cURL programs load but 
GTK programs don't, that's sinister

What I found for sure is that the Android Bionic C library has an 
atexit implementation