World: r3wp

(btw, I'm not arguing , I really wondering what's the difference)

But they're not better placed elsewhere. CATCH already has the code 
in it to do this task. Putting it elsewhere would mean moving that 
code to an internal function that CATCH calls. Not a bad thing, really, 
but that is the practical reason. Also, we don't want to polute the 
namepace in lib with too many predefined words that could be better 
used for other functions.

Maxim, the reason that SANDBOX would need to be mezz is because there's 
more to sandboxing than catching stuff. You also have to set up a 
context full of safe functions for the sandboxed code to use, including 
wrapper functions. That is mostly mezz work. We don't want to waste 
the word SANDBOX on anything less than that.

ok, good point.  this even adds some strength to my extension module 
  /pre   wish for allowing exported words not to be overwritten by 
standard mezz code.

That is the general module override policy, yes.

no brianh... I don't want the actuall default mezz code to be used 
*at all* I want my version to be become the standard mezz used by 
system.

That is the general module override policy, yes.

no, how I see it is that currently,  if I define 'SANDBOX, export 
it, any mezz code using sandbox will not be using my version... but 
the one within the mezz module.

That is why I had trouble understanding your request at first. What 
you were requesting was already the override policy: first come, 
first served.

since it would redefine the 'SANDBOX function... unless I'm totally 
missing how modules bind stuff.

Sandboxing would require replacing the DO* and MAKE-MODULE* intrinsics 
for the sandboxed code as well. However, *you* would need the non-sandboxed 
mezz functions to *implement* the sandboxed functions.

Embedded extensions with the premezz option would necessarily not 
be useful for making sandboxes. Replacing the mezz code with your 
own mezz code is as simple as replacing the mezz code with your own 
mezz code - no embedded extensions necessary.

But still, mezz code shouldn't override premezz-defined words, because 
that would violate the standard override rules (don't, unless doing 
so explicitly).

but the mezz code won't be using my version since it's also definint 
the same word... for example (algo code, not explicitely working 
r3 code):

; pre-mezz exported
my-func: does [print "a"]

mezz: mezz-module [ 
	my-func: does [print "b"]
	print-my-func: does [my-func]
]

this is what I expect to happen:

>> mezz/print-my-func
== "b"

but I want(need)
== "a"


now I'm not toally clear on how the mezz is being defined, (a do 
block, a module, a contex, whatever) but it woudn't make a difference, 
AFAIK.

DO/SECURE ... thanks for the clarification. Brian.


What could be quite useful then, would be DO/SECURE having a parameter 
block of SECURE settings. But it can only tighten existing SECURE 
settings, not loosen them.


The DONE thing would execute under the tighter policies; and they 
would revert when it exited/returned/quit/crashed etc.

That would be a very useful tool for creating sandboxes.

I agree sunanda, restrict file reading to a specific directory when 
loading application plugins, for example..

Maxim, you do realize that the premezz option for embedded extensions 
isn't implemented yet, right? So how it is done right now doesn't 
matter. When it is implemented it will follow the standard policy 
:)

That is why I got confused by your request: I thought you were asking 
for something different from what we were going to do anyways.

well, the above shows that what I wan't can't be done in the *current* 
standard policy... how would get  == "b" right now?

Explicit override of a module/extension loaded after the standard 
mezz.

in any case, my request made explicit what IMHO needs to be done... 
it wasn't very obvious from the original idea.

of a -> in a

we'll see when it gets done... and I'll be the first in line to test 
it   ;-)

SECURE is a mezz in R3, so DO/secure would need to be implemented 
in the intrinsic DO*. But It might be better to add as a SECURE option 
instead.

Right now SECURE is self-contained. If you make DO* implement DO/secure 
that would make DO* less replacable. If you implement it as SECURE/do, 
it would be easier to do without breaking SECURE's security.

maybe the policy system on which secure is run could use a stack... 
so that we could do secure/push  secure/pop style pairs.

That wouldn't work, because you would have to ask user permission 
to pop, at which point we are back in the same situation.

The only way to get around SECURE's user request thing securely is 
to do it within SECURE, and restore it before the initial call to 
SECURE returns.

Of course this means that security would be task-local, which would 
have interesting advantages as well.

All this might mean making a MAKE-TASK* intrinsic similar to MAKE-MODULE*, 
but we can't know that yet.

yeah... but something like:

secure/do [... policies ...] [

	... code ...

]


looks like the best way... though the current native security system 
doesn't support this natively.   the set-policies/get-policies do 
not operate within a stack frame but within a global heap.

it would require the security system to use the stack frame to push/pull 
"current" policies to the global set (of each task)

Maybe not, we might be able to do this in SECURE itself. But it would 
require the policies to be task-local.

The increasingly off-topic nature of this conversation makes me wish 
more and more that this was R3 chat. Then we could move messages.

off-topic?  we changed topic.

Core is for issues that aren't as R3-specific as our conversation. 
We should be discussing CATCH/all and SECURE/do in the !REBOL3 group.

but I am realizing there might be an R3 topic missing.   something 
like new ideas, proposals, etc.

to make it clear that discussions there aren't related to *Using* 
R3 but in how it can be improved.

all covered by !REBOL3

That is what !REBOL3 is for. Once the ideas are established we make 
topical groups for them, like !REBOL3 Graphics.

Formal proposals go in CureCode (eventually, after discussion in 
!REBOL3 or on a blog or wiki page).

well, where is generic *using* R3 group then?

anyhow... its just that more groups is faster than really big ones, 
so separating the use and proposal discussions seem to be a good 
thing in my mind.

Brian, in

http://www.curecode.org/rebol3/ticket.rsp?id=1744&cursor=2

you wrote: "We already have local THROW and RETURN"


If we do, I must have missed them, knowing only the global variants. 
Can you point me to them?

I would say, that this looks as a terminological misunderstanding 
to me.

I explain it for RETURN, but the case of THROW is similar. Normally, 
when you use RETURN in REBOL, it is a global function that does something. 
I demonstrated, that it is possible to have a similar construct (possibly 
even using the same name), which could work as "local" in the sense, 
that it would be assigned to a locally-bound 'return word. Such a 
"local RETURN" would, in fact, be able to "jump many levels up", 
not just one level, as the current global RETURN does, since it would 
be tied to its "function of origin".

return/to

instead of "tied" I should rather have said "bound"

(i.e. no refinement is needed)

>> a: [ b [ c [ 1 ]]]
== [b [c [1]]]
>> d: 'b
== b
>> e: 'c
== c

using a, d, and e, how would I get the value "1" ?