World: r3wp

Or, I could just create anonymous functions  as in 'do funct [][ 
............. ]

I built my own decoder for the query-string and it works pretty good. 
 But I was wondering what the /only refinement is for  construct. 
 This looks new in R3.

I really wonder what's RT cooking (or not) right now :-) The silence 
is really strange ...

They probably had to break away and do some projects to pay some 
bills.

Is there a list of  words reserved for parse, as

>> parse "a b" [ copy limit to " " ]

** Script error: PARSE - command cannot be used as variable: limit
** Where: parse
** Near: parse "a b" [copy limit to " "]

>> parse "a b" [ limit ]

** Internal error: reserved for future use (or not yet implemented)
** Where: parse
** Near: parse "a b" [limit]

CONSTRUCT by default translates the built-in logic words to logic 
values, unset values to none, lit-words to words, and lit-paths to 
paths. This makes it easier to use it to handle headers. CONSTRUCT/only 
doesn't do any of those things - it only constructs the object with 
the data provided.

Sqlab, 'limit is reserved for a planned parse ooperation that Carl 
doesn't know how to implement yet.

Sunanda, once again you seem to be the best source for CureCode tickets 
that show off the most subtle distinctions in REBOL semantics, even 
if most of those tickets have to be dismissed. The latest example 
is bug#1506, where you give an example of wanting to catch an error 
before it is an error. Great stuff :)

Thanks for the kind words, Brian,

But I am not sure we can yet agree on the issue involved. I've added 
my response to your detailed analysis:
  http://www.curecode.org/rebol3/ticket.rsp?id=1506

Without the ability to catch _all_ errors, REBOL is vulnerable to 
sudden, unexpected and unhandlable crashes.

attempt needs to as lean as possible since it could be within loops 
being called a lot.  So I would propose that another solution might 
be to add another function.  Like to DEFUSE the block being passed 
to ATTEMPT.  So you can do something like ATTEMPT DEFUSE [some block] 
     The defuse function would return/pass the defused block to attempt 
to be evaluated.

This way your only evaluating the DEFUSE code when needed so that 
ATTEMPT is free to be used in loops in controlled code.

Also, thanks for the explanation Brian, I see you answered my question 
regarding Construct.

Great analysis Brian. And I think Sunanda's point about arbitrary 
code is the key element for me. Some things we can address with language 
"Don do that", but error handling like this is very important to 
get right, and explain clearly (with examples of how to write robust 
apps).

I've given it some more thought and think I have combined two issues 
that could better be dealt with separately:

1. TRY and ATTEMPT as ways of protecting my code:

Generally, the current behavior is surprising but in most cases acceptable.

It is rare that something as stupid as attempt [exit] would make 
it to production status. So, in many cases  no problem. [perhaps 
an odd problem if my app is generating code (eg a genetic algorithm). 
But knowing the problem, that could be guarded against]. 

2. TRY and ATTEMPT for protecting arbitrary code

As Gregg suggests, that needs a careful, systems-level design to 
get right and to make robust. REBOL3 offers some help (SECURITY policies, 
ATTEMPT, TRY, CALL) but isolating code into a safe sandbox, and recovering 
from any possible error/lapse/attack is not something the language 
alone can provide.


Still, making TRY and ATTEMPT fully predictable [succeed or return 
an ERROR] would be most welcome!

The trick, Sunanda, is that the code that you want ATTEMPT to catch 
isn't actually erroneous. EXIT itself never generates an error - 
it basically is like a fancy goto that has to be caught by a handler. 
However, the handler can trigger an error (the one that you see) 
if the goto supposedly isn't handled; actually, all such goto functions 
are always handled and never cause an error directly, it is the handlers 
that cause the error.


The problem is really one of perception: Code that you think is erroneous 
(but isn't) is not triggering errors (and shouldn't), and the code 
that is triggering the error is not actually inside the code block 
that you are passing to TRY or ATTEMPT. Perceptual problems are tricky 
- either you have to change your perceptions, or rewrite the basic 
semantics of the language. Which is easier in this case?

ATTEMPT [exit] is never an error on its own. The error strictly comes 
from the context surrounding that code, not the code itself.

But 
  exit
_is_ an error on its own.

It is hard to see why ATTEMPTing an error "is never an error on its 
own", especially as trying it by itself in a console does create 
an error.  
  exit  ;; REBOL says is an error
  attempt [exit]  ;; Brian and I disagree if this is an error

it creates a horribly inconsistent mental model.

You could create a trivia/gotcha quiz arond this. Which of these 
stop with an error?
  attempt [throw]
  attempt [throw 0]
  attempt [throw/break]
  attempt [throw/break 0]
  attempt [throw/name]
  attempt [throw/name 0 0]
  attempt [throw/name 0 'x]

But it's not EXIT that is generating the error. EXIT itself is innocent.

Sunanda, you are ignoring context. None of those generate an error. 
It is the code surrounding that code that generates the error.

Wait, the THROW/break ones always generate an error. THROW doesn't 
have a /break refinement.

But the only code surrounding it is the console!

Yup, that is what is generating the error, the console.

And the first two THROW/name examples are wrong too, because of argument 
compatibility.

Then the console is broken!

No, it's doing its job. It is only context that makes that code erroneous 
(except for 5 argument errors in your examples).

THROW 0 is always correct in and of itself. It's not THROW's fault 
you called it outside of a CATCH, it's yours.

So how to catch concole errors then?

Simply put - we have to have chance to catch ANY level erorrs - your 
app can't crash on you, without your control imo ...

The problem is that the code he is complaining about isn't actually 
erroneous.

How then can I get this code, executed from the command line, to 
always quit?
  r3-a97-3-1.exe --do "print true attempt [exit] print true quit"

does it not print an error message?

It's the missing CATCH that is the error, not the THROW.

I guess ATTEMPT is no longer an extension of error? try like in R2.

No, but it works the same, just faster. Almost all functions that 
had a [throw] attribute in R2 (or needed one, like ATTEMPT) were 
converted to natives in R3. We're still waiting for the new equivalent 
of the [throw] attribute to be added to R3 - right now USE, OBJECT 
and CONTEXT are the only built-in functions that still need it, afaik.

Note that the ticket was marked as a problem, not dismissed (yet). 
The problem was explained in the comments, and more thoroughly now 
in my more recent reply there.

I think I can answer my own question about executing arbitary code.

Just tried the ancient error? try technique:

   error? try [break]  ;; I'm happy
   attempt [break]   ;;  still think this is a bug!

Actually, the first is an error too. It turns out that the way BREAK, 
EXIT, RETURN, THROW, HALT and QUIT work is by throwing pseudo-errors 
that are technically instances of the error! type, but not really 
errors. The ERROR? function disables that throwing for all error! 
values, even the fake ones. It's an error in ERROR?.

There's even a CureCode ticket for it, which you referred to in your 
comment.

It's the same error as RETURN BREAK.

From my perspective, attempt [break] is working correctly. ATTEMPT 
has nothing to do with the BREAK, it simply passes it to the outer 
context (if you can say that) and then the BREAK doesn't hold up, 
because it's not inside a function. Seems simple to me.

Loops, but yeah.

yes, sorry, loops, not functions.

loop 2 [attempt [break]] works as expected.

>> a: does [attempt [exit] 1]
>> a
>>

Looks fine and dandy.

What would you expect from:
  loop 2 [print true attempt [break] print true]
true printed 0..6 times?

Or:
  loop 2 [print true attempt [continue] print true]

Once, and it did.

Twice, and it did.

The question (only for Carl) is whether task-local runtime contextual 
information can be made available to BREAK, EXIT, RETURN and THROW 
to let them know that they are going to be handled by the console, 
which would let them throw the error that the console should be throwing, 
on behalf of the console. Basically, letting them be more polite. 
The problem is that it is *really* likely (only Carl would know) 
that this would slow down all function! and closure! calls, all loops, 
and every call to DO (even indirectly, as in IF) by quite a bit. 
It could make R3 a lot slower (maybe several times slower).

I'm not sure what you would expect here. Wrapping break and continue 
in attempt has no effect, because we know there are no errors inside 
the attempt block and the context outside is correct for break and 
continue. The attempt has absolutely no effect here.