World: r3wp

I think that user-context cloning should be considered as an option. 
 even without tasks.  it might help in providing a proper sand-box. 
  though I can see some things that it currently doesn't cover on 
its own, it would allow the basis for a strong model.

something like:

ctx: clone-user-ctx


ctx/my-func data ; (this becomes shared, so you decide how this is 
managed, copy if required)

what I need:  ctx/some-value

ctx: none  ; recycle it.

All you need to do to sandbox some code is isolate it and give it 
its own lib and user contexts.

yes... but "it's own" should allow a clone of the "current" one.

A user context by default only contains a reference to system. Everything 
else comes from lib. Cloning lib is more effective.

I'm not talking about fast, I am talking about easy and practical. 
 the user-context already exists so Cloning it should also be an 
option.

make it lib by default (which I agree it should be) but in many cases, 
that will lead to *very* complicated or even impossible to replicate 
data setups.

shared stuff can be tampered.

when its protected, then it can't be used in all circumstances.


a perfect clone of the user allows tampering, without the danger, 
since it can't affect you anyways.

A standard sandbox lib could be provided that contains a safe version 
of the standard lib that R3 comes with. Then you could derive your 
own safe lib from that one, to add your own predefined functions. 
No clone of the user context would be necessary. And for that matter, 
you should assume that cloning the user context is impossible because 
of cyclic references.

actually, cyclic references is one of the specific reasons for a 
clone-user-context native ! ;-)

The SANDBOX function wouldn't then need to do anything custom to 
the user context that the script it is running is using. All it would 
need to do is create a safe system object, create an object that 
references that object using the 'system word, and set the lib and 
security settings to those provided as arguments to the SANDBOX function.

I agree on all points.

The object with the one 'system word in it would be the script's 
user context. Everything else would come from the lib.

A different lib than the one that regular scripts use, of course.

#1743 added to have QUIT with no /now, #1744 added to have CATCH/name 
use EQUIV? comparison (considering contexts), and #1520 scaled back 
to be the CATCH/name true option, no other options added.

Also changed the comment in #1742 to match the new combined model 
of #1518, #1520, #1742, #1743 and #1744.

#1521 would be better to do as a separate function (perhaps RECOVER).

I would be just thrilled to see something like PROBE/SOLVE 

I have trouble "understanding" how to read rebol code.  I'm getting 
there, but still I make mistakes.  I would love to see a "step by 
step" breakdown of some rebol code.


I'll give you a good metaphor:   Remember Algebra, with parethasis 
and the steps you took to solve a problem:

( (a * 2) + (b / 3) ) / 5   Then you substituted for your variables 
step by step and solved the problem.  I'd love to have rebol do something 
like that.  So instead of one line like PROBE, you could get several 
lines, that show how the function was evaluated to arrive at the 
final result.  Maybe TRACE does this?


All in all, I'd like more debugging tools, or at least some expanded 
documentation on how to debug rebol code faster!  Thanks

TRACE does this, but it may be hard to read.

trace/function too

Pat, remember that you can replace the function building mezz code 
like funct and func.   though its not for novice users, since you 
do have the source when you 'SOURCE these builders, it can be quite 
easy to tweak them so they do a few things more...  like add a little 
break point at the end of each func and probe all the collected words, 
in FUNCT.


with a global word you could control if this tracing occurs, just 
by setting it to true or false, dynamically.

Ladislav and I have been collecting the pros and cons of the various 
issues and proposals related to escape functions here: http://www.rebol.net/wiki/Exceptions

wow, that is a very nice document, I hope it makes its way to the 
official r3 documentation when an "official" R3 specification is 
finally written, after all the tweaks to the language.

Keep in mind that only *one* of those proposals for the new model 
of function behavior would be done. I am in favor of either "Definitional 
return with an option to not define RETURN and EXIT, dynamic return 
as a fallback" or "Definitional return with an option to not define 
RETURN and EXIT, no dynamic return". How about you?

Just tweaked it a little - something wasn't a disadvantage, it was 
just part of the proposal.

right now..  my brain would choose this way:

my-brain [ ]

hour: 12h35AM
options: [
	"Dynamic return with optional transparency"
	"Definitional return only"

 "Dynamic-return-only functions vs. option of definitional-return-only 
 functions"
	"Dynamic return with a definitional return option"

 "Definitional return with an option to not define RETURN and EXIT, 
 dynamic return as a fallback"

 "Definitional return with an option to not define RETURN and EXIT, 
 no dynamic return"
]

either hour > 00:00:00 & hour < 06:00:00 [
	select options random length? options
][

 write altme://!REBOL3 Proposals/answer  read http://www.rebol.net/wiki/Exceptions
]

and my-brain doesn have the same seed as rebol, so you can't guess 
my option right now  ;-)

Let's just make it a standing question then :)

I just finished clening up my public xml library for Graham to test... 
if all goes well, I will proably upload it to rebol.org this week.

so I'm pooped.... time to fire up the PS3.

Ah, I was going to lie down and watch TV on my computer in the other 
room :)

If a function can't be rewritten so it doesn't use inner functions, 
you have no recourse.

What's that supposed to mean?

Making definitional return optional means that this option would 
need to be specified in the code that ''calls'' the functions that 
would benefit from it, rather than the functions themselves. This 
means that the option would need to be specified a lot.

What is that supposed to mean?


With optional definitional-return-only functions I would simply define 
a mezzanine USE with a definitional return, at which point it no 
longer swallows dynamic return. A caller of USE then does not have 
to worry about this at all.

you have no recourse

 is a polite way of saying "you are out of luck". At least regular 
 programmers would be out of luck there - I'm sure someone like Ladislav 
 could come up with an arcane workaround, or you could give up on 
 RETURN and EXIT and use another escape function instead, like THROW. 
 But I assume that you know what I meant by "recourse", and want the 
 point explained.


Pardon me, that question needs some background info. The return models 
are being used to deal with a basic problem of functions catching 
RETURN and EXIT when you don't want them to. This is the case with 
many mezzanine control functions which take and execute a block of 
code. We have been putting requests for new mezzanine control functions 
on hold for quite a while because they can't currently be made to 
pass through RETURN and EXIT, but USE and COLLECT got through before 
we started that, and the restriction is lifted now.


Let's use USE to illustrate, ignoring for the moment that USE *can* 
be rewritten so it doesn't use an inner function.

use: func [
    "Defines words local to a block."
    vars [block! word!] "Local word(s) to the block"
    body [block!] "Block to evaluate"
][
    apply make closure! reduce [to block! vars copy/deep body] []
]


USE uses an inner function to create a binding for its words (the 
closure!). For the dynamic return we have now, the inner function 
catches returns from the body, but even if it didn't the USE function 
itself would catch those returns as well.


One proposal to solve this would be to switch to definitional return, 
which means that RETURN and EXIT would be redefined in the code block 
of a function to return directly to that function, not any intermediate 
function in the call chain. This would solve returns being caught 
by the USE function itself, because the body of code that contains 
the 'return or 'exit words is not physically in the code of the USE 
function, it is only referenced by word. However, that block of code 
is used by the inner function as its code block, so the inner function 
would redefine those words and catch the returns.


If your function uses inner functions like USE does, and can't be 
rewritten to not use them, and you are using definitional return 
without the option to turn it off, then the inner function will localize 
RETURN and EXIT every time.


As a caveat, I wrote that phrase before I came up with the workaround 
in the next section of using direct references to the RETURN and 
EXIT function values instead of referring to them by name, which 
avoids the rebinding issues because no words are involved. See the 
code in http://curecode.org/rebol3/ticket.rsp?id=637to see what 
that workaround makes your code look like.

That was in answer to your first question. Now for the second.

That has nothing to do with inner functions.

You can safely use the inner function as long as you don't copy the 
code into the body of the inner function, which causes it to be rebound.

Thanks for all the effort that went into that doc! I've skimmed it, 
but will have to find time to read it in depth and digest it.

Of course, at this point you don't need to use an inner function 
at all, you just use bind + do.

USE uses the body of the affected code *as* the body of the inner 
function, so it *is* a good example of this pattern, if you ignore 
the fact that USE in particular can be rewritten so it doesn't use 
an inner function.

But the claim is even wrong for this example.

Keep in mind that we use USE to illustrate because it is simple and 
shows a lot of the problems we are trying to solve in its existing 
code. USE is being used as a standin for the many other functions 
that would be affected by these issues. The fact that USE can be 
rewritten doesn't mean that the other functions can also be rewritten.

All you have to do is construct a correct inner function, instead 
of an erroneous one.

USE's inner function is not erroneous, not in the slightest bit. 
The whole point of it is to rebind the code block passed to USE.

Yes, then simply rebind it properly.

It does rebind properly.

Your example does not. It improperly rebinds a definitional return.

Instead of only the local vars.

You grabbed that phrase that I was answering from the section where 
binding with definitional return was the only way to bind. There 
is no option in that section (and that fact is listed in the advantages). 
In that section, definitional is the only way to bind.

Sure there is. BIND + DO.

That is rewriting to not use an inner function. Which that phrase 
was referring to cases where that is not possible.