World: r4wp

After trying to use the new exception handling in the interpreter 
to implement EXIT/RETURN, I realized that the current behavior of 
the [catch] attribut is not suitable in a intensively recursive environment. 
So I had to change the moment the exceptions are caught to an earlier 
time. Now, it works like this:

	foo: does [
		print "3"
		throw 100
		print "KO"
	]

	bar: func [[catch]][
		print "2"
		foo
		print "4"
	]

	print "1"
	bar

will output: 1234


So, now the [catch] attribut resumes the execution at the current 
level, instead of the parent caller level like before.

The catch flags position on stack has been changed to a safer place, 
so it's now resistant to a "dirty" stack left by user code (unbalanced 
PUSH/POP actions at the exception raising point).

A [catch] flag will have no effect on exceptions launched from the 
same level (enables re-throwing exceptions).

EXIT and RETURN have been implemented for the interpreter too now. 
All related tests are now passing. An important fact to note, which 
differs from the Rebol way:


EXIT and RETURN are dialect keywords in Red, not native functions. 
Both the compiler and the interpreter are processing them as part 
of function's body dialect.

@Ladislav, I know you don't care much about Red, but you might be 
pleased to see that some of your old propositions for Rebol found 
their way into Red. ;-)

Can't speak for Ladislav, but maybe he is mostly busy with other 
stuff, so he'll wait, how Red turns out in the end :-)

So, now as exceptions are working, my typical - what's next? :-) 
Dyn-lib emmiter? Contexts? IO? :-)

Shared lib generation for Mac OS X and Linux.

Does that include ARM?

Not sure if you mean for exceptions or shared libs, so:
- Exceptions: I will push the upgraded ARM version in a few hours
- Shared lib: yes, we will support it on ARM too

I meant shared libs

...you might be pleased to see that some of your old propositions 
for Rebol found their way into Red
 - yes, that is great!

EXIT from a func exits the console. Is that intended?

N ope.

The console needs a [catch] somewhere to avoid such exceptions reach 
global code and exit from console.

Ahhh, makes sense.

Should I log it as ain issue?

No need, I will process tonight as I need to do a bit more work on 
exceptions (like documenting them).

OK.

Gregg, can't reproduce your console issue, here's the test code I'm 
using:

red>> foo: func [][print "1" exit print "2"]
== func [][print "1" exit print "2"]
red>> foo
1
red>>

Hmmm, neither can I now. Thanks for checking.

Uncaught exceptions in Red/System (THROW) currently won't stop execution 
and report an error when reaching global code, but would just resume 
from there. I wonder if this is really the best behavior for the 
user, or if an error shouldn't be forced... OTOH, there is no way 
currently to catch an exception at global code level, so if the behavior 
is changed to an error, it might result in users making wrapper functions 
to avoid the error and resume at global level ...

I guess I will probably keep it as is for now, we'll see when we'll 
have some way to catch exceptions manually at global level.

You could still check system/thrown though, correct? And if you wanted 
to catch them, you could just have a MAIN func?

Correct. Yes, it is possible to wrap all your global code in a MAIN 
func.

That should be comfrotable for C programmers, yes?

Even if not required.

Yep, C coder could feel easily at home. From what I've seen so far, 
people knowing C and Rebol can learn and use Red/System in a matter 
of hours. Even for pure C coders, learning Red/System should be trivial.

Trivial is never trivial, especially on computers...

UTF-8 encoding would be very welcome. My I/O frameworks are of little 
use without it

Red/System c-strings are UTF-8 compatible.

I mean my ongoing request for getting UTF-8 in routines

As I said above, that part is not implemented, it will be once the 
work on Red's I/O will begin.

Yes, you said you might speed it up if I have a big need for it, 
so I'm expressing my need

But someone could contribute string! <=> UTF-8 conversion routines 
in the meantime.

I'm afraid my short-term schedule is already full, I've kept postponing 
very important parts for months, I need to get them implemented now 
(shared libs, error!, typeset!, object!).

I think that those UTF-8 conversion routines would take at least 
two days of work to get implemented and debugged.    I'll see once 
I get shared libs done if I can afford them before working on the 
other urgent tasks.

It's just that I thought Unicode was already there. Most of my future 
work is blocked by it

Unicode support is there, but we don't have all the external encoders/decoders 
yet.

It's nice that you can get data in, but it's useless if you can't 
get it out

We have hardwired the stdout/stdin Unicode support because we don't 
yet have the I/O infrastructure for Red (ports and devices).

True, but I do have the infrastructure. Just can't really use it 
this way

Well, as I said, someone could contribute those UTF-8 conversion 
routines.

I think Peter already did some work on it as have Rudolf (meijeru).

I wanted to publish an article with examples on the birth of the 
interpreter and the porting of the bindings to Red, but if a simple 
READ WRITE example doesn't work, I think it's too early to talk about 
it

I will have a look at it once shared libs are done, that's the best 
I can do for now.

OK, but I can't imagine what I would do with shared libraries if 
I can't get string data out

Shared libraries are on the critical path to Android support for 
Red and I've delayed it way too much already.

Same thing: what would you do on Android if you can get data in, 
but not out?

It's worse than having no Unicode, then you can at least get out 
what you put in