World: r3wp

Outside of rebcode, you can't goto down, but you can goto up with 
CATCH/name and THROW/name. Of course the structured goto replacements 
still work (RETURN, EXIT, BREAK).

in fact i remember having to simulate a goto command when i tried 
to develop a Z80 emulator.
i had build a simple engine working like that:
code: [
	[ some code....]
	[ some code...]
	[ some code ... GOTO: 1]	; goto the first line of code
]
GOTO: 0
forever [
	GOTO: GOTO + 1
	do pick code goto
]

That's a pretty standard switch interpreter model.

yep, even if there is an error in my code, it's very easy to do

I was tongue in cheek on that, but then I'm not surprised there is 
an "elegant" goto in REBOL.  Thanks, I am out of the woods with my 
problem, thanks to the best help-desk in the world!

print "Continue hack for a forever loop using Catch and Throw"
n: 0
forever [ ;from sqlab
	n: n + 1
	print join "top of FOREVER LN:" [n]
	catch [
		print "top of CATCH"
		if n > 100 [ break ] 
		if random 10 > 5 [ throw ]
		print "BOTTOM BELOW THROW CONDITIONAL"
	]
	print "BOTTOM BELOW CATCH"
]
print "BREAK forever loop and halt"
halt ;this is what I did to mess with it, sqlab

continuing: func [code [block!]] [catch/name code 'continue]

continue: func [/return value [any-type!]] [throw/name get/any 'value 
'continue]

in that case a simple exit or return is enough:
continue: :exit
continuing: func [code][do code]

No, that would capture real exits and returns.

like in your case

Then you add the appropriate function attributes to my case to make 
sure that exits and returns aren't captured ([throw]?).

that should be ok

according to forskip source, perhaps a dual [throw catch] attribute 
is required, i'm not well versed in using such tricks

The [catch] attribute is like a CATCH block for errors in the function, 
in this case used to catch the error! thrown in the source on the 
first and fifth lines. There is no need for the [catch] attribute 
in the CONTINUING function above, or for any function attribute in 
the CONTINUE function above.

By the way, R3 doesn't need anything like the [catch] attribute because 
it does stack traces on errors.

BrianH, in R3 some functions are not any more natives (ie minimum-of). 
Is that meaning that they will be slower ?

In some cases, yes. In other cases, changing the functions to mezzanines 
has allowed us to get algorithmic speedups. In more critical cases 
(like loops), functions that used to be mezzanine are now native. 
The overall speed of R3 is greater.

repeat  n 100 [
	print join "top of loop LN:" [n]
	catch [
		print "top of CATCH"
		if random 10 > 5 [ throw ]
		print "BOTTOM BELOW THROW CONDITIONAL"
	]
	print "BOTTOM BELOW CATCH"
]

regarding the source of minimum-of and maximum-of, i assume they 
fall in the wrong side

They are infrequently used functions, and as such are a good candidate 
to be mezzanines, for 2 reasons:
- Frees up some native space for more important functions.
- Easier to modify or replace with better functions.

The really interesting thing is the intrinsics - REBOL code called 
internally by natives.

i see, sort of hooks, but currently there's only 3 intrinsics func, 
is that enough ?

For now, there are 5 intrinsic functions. There can be more later.

it could be amazing if we have an intrinsic func for each type of 
value (when they are evaluated) but i assume it would be very slow

You are thinking of actions.

(seems devbase is not up to date, i see only 3 functions)

There are several dozen actions.

in which group of devbase are they filled (actions) ?

DevBase is up to date (as of this week, except for the View stuff). 
The other intrinsics are defined elsewhere in the source.

Actions are native code, which is not in DevBase yet.

ok, i see the actions now, do u say that we can redefine actions 
?

efishant - for what you want to do with the loop just put the while 
loop inside a function (assuming you manipulation a series) and then 
have it break out on a conidtion is met and then change the series 
to the desires position and pass back to the function if needed. 
 Not sure exactly what your trying to accomplish.

No, but actions are handled on a type-specific basis, and R3 will 
have user-defined types.

Also efishant regarding ports you don't need to use port/state/index 
as you can just use 'at.

The list of actions is fixed (for the REBOL version). Each datatype 
has its own set of action handlers though.

Paul, does the INDEX? function return the port/state/index of a port! 
type?

It returns an integer

integer!

i see Brian, so that we can create new datatype (overriden the primary 
ones) so that we can use our own combinations of actions

I mean, is that integer! the value assigned to the port's state/index 
field?

yes it is

Steeve, I'm not sure how well you can override a built-in types (not 
decided yet), but you will be able to create new ones.

My belief i s that difference is that index is used to move the head 
to the specific position of the file where as using 'at keeps you 
at the head of the file.

But I don't know and asked before here and got no answer.

Paul, Brian, others, i used to manipulate the port/state/index with 
read-io and write-io because it's faster (i made some tests).

But the main reason is that we can directly manage the buffer used 
so that we avoid some overhead existing in the standard port handler

Paul, you don't move the head, you move the position. AT and SKIP 
are relative to the current position, 1 or 0 based respectively. 
INDEX? returns the current position, relative to the head.

How did you do those test STeeve?  I have been interesting in changing 
Trebases operation depending on how that works.

Right Brian but it doesn't seem to.

I'll defer to Steeve on this one - I am more familiar with the R3 
port model than the R2 one.

Not with the file port Brian.  At  seems to always work from the 
head.