World: r3wp

CC -> MAKE-CONTINUABLE ;)

Very understandable, but a little bit too long for my taste

I can't think of a better name. The reason is because it shouldn't 
be there at all. I think all the rebol loop constructs should be 
adjusted to use CC by default.

All REBOL loop constructs use CONTINUE, but, unfortunately, not in 
R2 :-(

Well, there's a wish...

I don't think you get CONTINUE in R2, if you don't want this "cheap 
one"

Hmmm... hard decision.

On the balance of things, I think it would make things better; code 
more readable and more consistent with R3 code, so I'm for it.
A better name for CC is definitely needed, though.

What amazes me, (as always in REBOL) is, that the hardest part is 
to find the best name, not to implement the feature :-)

Well, that just means that the name of a feature is really part of 
the feature.

Regarding the CONTINUE in R2 - I may be wrong, though, maybe Brian 
would know better?

But, of course, Carl would know best!

What do you mean "Regarding the CONTINUE in R2" ?

That you think it's not implemented in any loop construct (even under 
a different name) ?

I wrote: "I don't think you get CONTINUE in R2". the above is just 
explaining, that I may not be the one knowing the policy in this 
respect

replace "get CONTINUE" by "get native CONTINUE" to make it more understandable

Ah yes.

Well... I think we should still aim high and make a wish.

Sure

How about a C-AWARE name, it looks a bit shorter, would it sill be 
acceptable?

sill: :still (pardon the typo)

http://www.rebol.org/view-script.r?script=c-aware.r

CC makes me think of "Call with Continuation", but I agree that MAKE-CONTINUABLE 
is a little long. Just CONTINUABLE? Without 'continue in the name 
somehow, even if abbreviated, you lost the connection to the keyword.

It would be nice to have /PART refinement for SWAP.

CC is also commonly known in digital photo area as Comment & Critique 
....

Ladislav, your request to make HALT catchable was in CureCode already 
as #1520. Please add your concerns in a comment there. That ticket 
needs a use case to catch HALT in addition to everything else.

According to that use case CATCH/all would catch QUIT/now as well 
- you should mention that too.

There is no need to worry about the name CC - it won't be used. A 
CATCH option is more likely.

Oh, nevermind about the CC. I missed the change in subject :)

CONTINUE is more likely to be added as a native in R2 than it is 
as a hack. We already have BREAK, so the mechanism is there.

use case is simple to catch halt... make sure sandboxed code doesn't 
stop the interpreter.  same for quit/now.  only the outer app should 
be allowed to use those.

Right, but the top-level script *is* the outer app, so these need 
to be made available at least at that level.

yes... which is why putting a catch/all when executing code in a 
sandbox (I often use CONTEXT [ ]   to do so)  is very usefull to 
prevent the outer script from halting or quiting because of some 
externally loaded code..

If MAKE object! specs catch RETURN and EXIT, that's an error.

I don't think it does.

CONTEXT catching RETURN and EXIT is error #520.

Sorry, #539

An R3 suggestion.....

-- Ability to execute HALT, QUIT etc should be controlled by SECURE

-- DO should have a refinement DO/SECURE ... meaning the DOne thing 
cannot change any SECURE settings
That would be a big step towards safer sandboxing.
-

what I mean is this:

catch/all [
	context load %file.r
]

this has to be completely 100% bullet proof.

where you can replace 'CONTEXT by any of the control/eval funcs

Look at the #1520 proposal, with the clarifying comments. Combined 
with TRY it should catch everything short of an interpreter crash.

We want the separate TRY in order to distinguish between errors and 
unwinds.

Sunanda, SECURE isn't scoped, it is "from now on". You need user 
permission to undo it. If we did this with SECURE we wouldn't be 
able to quit our own apps.

maybe we could start thinking about using a new word for what we 
are talking about extending CATCH to do... its starting to look like 
a long list of groceries for a single word.


reading Andreas' notes on 'CATCH I agree that it should only manage 
throws.  

/all  should mean catch any named or unnamed throw


/quit /unwind and other proposals should fall into another function.

something like 'SANDBOX

CATCH is a sandbox already, just not a very good one. SANDBOX would 
need to be mezzanine because it would need to provide wrapper functions 
as well. And we need the subtle differences in the various CATCH 
options for different circumtannces.

Ah, a SANDBOX function sounds like a good idea.

well, I'd argue that its meant to do exception handling on ERROR!

I think we should even remove its /quit refinement.

Then we could get rid of CATCH/quit and move it to SANDBOX and also 
move the desired CATCH/all to SANDBOX.